Scribd
Upload
4 views3 pages

SDA Assignment

The document discusses microservices architectures, focusing on communication patterns such as synchronous (REST APIs), asynchronous messaging (e.g., Kafka, RabbitMQ), and event-driven architectures, highlighting their pros, cons, and use cases. It presents a hypothetical online banking system with various services and justifies the design based on scalability, fault isolation, and maintainability. Additionally, it evaluates microservices against monolithic architectures, emphasizing advantages in scalability, fault tolerance, and maintainability, with an industry example of Amazon's transition.

Uploaded by

ai.universe360
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
4 views3 pages

SDA Assignment

The document discusses microservices architectures, focusing on communication patterns such as synchronous (REST APIs), asynchronous messaging (e.g., Kafka, RabbitMQ), and event-driven architectures, highlighting their pros, cons, and use cases. It presents a hypothetical online banking system with various services and justifies the design based on scalability, fault isolation, and maintainability. Additionally, it evaluates microservices against monolithic architectures, emphasizing advantages in scalability, fault tolerance, and maintainability, with an industry example of Amazon's transition.

Uploaded by

ai.universe360
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

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. https://martinfowler.com/articles/microservices.html


 Amazon Builder’s Library. https://aws.amazon.com/builders-library/
 NGINX. Microservices Reference Architecture.
https://www.nginx.com/blog/introduction-to-microservices/
 Kafka Documentation. https://kafka.apache.org/documentation/
 RabbitMQ Documentation. https://www.rabbitmq.com/documentation.html\
 Netflix Tech Blog. https://netflixtechblog.com/

You might also like