Assignment: Designing Microservices Architectures
1. Microservices Communication Patterns: Analysis and Comparison
a. Synchronous Communication (REST APIs):
Description: Services directly call each other over HTTP using REST APIs.
Pros:
Simple and widely supported.
Easy to debug and monitor.
Cons:
Tight coupling and potential cascading failures.
Latency and availability concerns.
Use Cases
Suitable when real-time responses are required, such as user authentication, balance
inquiries, or booking confirmations.
b. Asynchronous Messaging (e.g., Kafka, RabbitMQ):
Description: Services communicate by sending messages to a queue or topic, which
other services consume.
Pros:
1. Loose coupling between services.
2. Improved fault tolerance.
3. Better performance for high-throughput systems.
Cons:
1. Increased complexity in message handling and error tracing.
2. Higher learning curve.
Use Cases:
1. Ideal for order processing, logging, notifications, and tasks that do not
require immediate responses.
c. Event-Driven Architecture:
Description: Services emit events and react to events from other services.
Pros:
2. High decoupling and flexibility.
Scalable and resilient.
3. Promotes reactive programming.
Cons:
1. Eventual consistency must be managed.
2. Difficult to trace full business transactions.
Use Cases:
1. Suitable for e-commerce, banking transactions, and audit trails where decoupling
and responsiveness are critical.
2. Hypothetical Microservices Architecture: Online Banking System
Services and Boundaries:
User Service: Handles user registration, authentication, and profile management.
Account Service: Manages bank accounts, balances, and account types.
Transaction Service: Handles fund transfers, withdrawals, and deposits.
Notification Service: Sends email/SMS alerts for transactions or changes
Audit Service: Maintains logs and records for all activities for compliance.
Loan Service: Manages loan applications, approvals, and repayments.
Payment Gateway Service: Integrates with external payment processors.
Data Flows and Communication Protocols:
User to Account Service: REST APIs for creating and managing accounts.
Transaction Service: Uses REST for initiating transactions and Kafka for transaction
updates.
Notification Service: Listens to transaction and user events via RabbitMQ.
Audit Service: Event-driven, subscribes to all service events for logging.
Loan Service: REST for loan application, Kafka for status updates.
Design Justification:
Scalability: Services like Transaction and Notification can scale independently.
Fault Isolation: If Notification Service fails, it won’t affect the core banking logic.
Maintainability: Clear boundaries simplify updates and deployments.
3. Evaluation of Microservices vs. Monolithic Architectures
Scalability:
Microservices allow independent scaling of services based on demand (e.g., Netflix
scales video streaming independently).
Monoliths require scaling the entire application, leading to inefficient resource usage.
Fault Tolerance:
Microservices isolate failures; one service failing does not crash the entire system.
Monoliths are more prone to system-wide crashes.
Maintainability:
Microservices enable easier updates, testing, and deployment due to service isolation.
Monoliths become increasingly complex and difficult to manage over time.
Industry Example:
Amazon transitioned from a monolith to microservices, which enabled faster feature
delivery, improved fault tolerance, and better team autonomy.
References:
Fowler, M. (n.d.). Microservices. [Link]
Amazon Builder’s Library. [Link]
NGINX. Microservices Reference Architecture.
[Link]
Kafka Documentation. [Link]
RabbitMQ Documentation. [Link]
Netflix Tech Blog. [Link]
