Skip to main content

ATAM Report: Library Management System

1. Introduction​

Purpose: This Architecture Tradeoff Analysis Method (ATAM) evaluation assesses the architecture of a library management system designed to handle user authentication, book management, borrowing, inventory tracking, and notifications.
Scope: The evaluation focuses on the microservices architecture, its inter-service communication, and its ability to meet scalability, reliability, and performance goals.
Stakeholders: System architects, backend developers, DevOps team, and library administrators.
Date of Evaluation: March 19, 2025

2. Business Drivers​

Objective: Build a scalable, reliable system to manage library operations for thousands of users.

  • Business Goal 1: "Support 5,000 concurrent users during peak hours."
  • Business Goal 2: "Ensure 99.9% uptime for critical operations (e.g., borrowing)."
  • Business Goal 3: "Minimize latency for user requests (< 1s average)."
    Key Quality Attributes:
    • Scalability
    • Reliability
    • Performance

3. Architecture Overview​

Description: The system uses a microservices architecture with an API Gateway as the entry point, backed by specialized services and asynchronous messaging.

  • Components:
    • UserService: Handles authentication and user management.
    • BookService: Manages book metadata.
    • BorrowingService: Tracks borrowing/returning of books.
    • InventoryService: Monitors stock levels.
    • NotificationService: Sends user notifications (e.g., due dates).
    • API_Gateway: Routes requests to appropriate services.
    • Kafka: Event bus for asynchronous service communication.
    • RabbitMQ: Message queue for task-based workflows (e.g., notifications).
  • Interactions:
    • API_Gateway routes HTTP requests to services.
    • Kafka propagates events (e.g., "book borrowed") across services.
    • RabbitMQ queues tasks like sending emails.
  • Key Decisions:
    • Microservices for modularity and independent scaling.
    • Event-driven design with Kafka for loose coupling.
    • RabbitMQ for reliable task queuing.

Diagram Reference: (Assume an architecture diagram exists showing API_Gateway → Services, with Kafka and RabbitMQ as connectors.)

4. Quality Attribute Scenarios​

Utility Tree:

4.1 Scalability​

  • Scenario: "System scales to handle 5,000 concurrent users borrowing books during peak hours."
  • Priority: High
  • Difficulty: Medium

4.2 Reliability​

  • Scenario: "System maintains 99.9% uptime for borrowing operations, even during service failures."
  • Priority: Critical
  • Difficulty: High

4.3 Performance​

  • Scenario: "User requests (e.g., borrow a book) complete in < 1s under normal load."
  • Priority: High
  • Difficulty: Medium

5. Analysis of Architectural Approaches​

5.1 Approach for Scalability (Microservices + Kafka)​

  • Description: Each service scales independently; Kafka ensures event propagation doesn’t bottleneck.
  • Trade-offs: Scalability gained at the cost of increased operational complexity.
  • Sensitivity Points: Kafka throughput depends on partition configuration.
  • Risks: Misconfigured scaling policies could lead to resource over/under-utilization.
  • Non-Risks: Microservices pattern is well-suited for horizontal scaling.

5.2 Approach for Reliability (RabbitMQ + Service Redundancy)​

  • Description: RabbitMQ ensures notification tasks aren’t lost; services deploy with redundancy.
  • Trade-offs: Redundancy improves uptime but raises infrastructure costs.
  • Sensitivity Points: RabbitMQ single-point-of-failure if not clustered.
  • Risks: Data inconsistency across services if Kafka events are lost or duplicated.
  • Non-Risks: RabbitMQ’s persistence ensures reliable task delivery.

5.3 Approach for Performance (API Gateway + Direct Service Calls)​

  • Description: API_Gateway routes requests efficiently; services respond directly for low latency.
  • Trade-offs: Fast responses traded for potential overload on API_Gateway.
  • Sensitivity Points: API_Gateway performance under high load.
  • Risks: Slow downstream services (e.g., InventoryService) could cascade delays.
  • Non-Risks: Lightweight service design supports sub-second responses.

6. Risk Themes​

  • Theme 1: Messaging Complexity
    • Impact: Misconfigured Kafka or RabbitMQ could disrupt event flows or task execution.
  • Theme 2: API Gateway Bottleneck
    • Impact: Overloaded API_Gateway could degrade performance across all services.
  • Theme 3: Data Consistency
    • Impact: Event-driven design risks inconsistencies (e.g., BorrowingService updates but InventoryService doesn’t).

7. Recommendations​

  • Recommendation 1: Cluster RabbitMQ for high availability.
    • Priority: High
  • Recommendation 2: Implement circuit breakers in API_Gateway to handle service failures gracefully.
    • Priority: Medium
  • Recommendation 3: Add retry and deduplication logic in Kafka consumers to ensure consistency.
    • Priority: High
  • Recommendation 4: Load-test API_Gateway to identify scaling thresholds.
    • Priority: Medium

8. Conclusion​

Key Findings: The microservices architecture with Kafka and RabbitMQ provides strong scalability and modularity but introduces risks in messaging reliability and gateway performance.
Next Steps: Implement recommendations and validate with a stress test by April 15, 2025.
Final Remarks: The system is well-positioned for growth but requires tuning to meet reliability and performance goals fully.