From

Monoliths
To

Microservices

Key to System Design Interviews

Microservices Architecture
Overview
1

2
Why Companies like Amazon, eBay,
Netlix, Spotify, etc. use
Microservices Architecture?
Service Registry Pattern
in Microservices
Service Registry Pattern
Product
Gateway Call IPs
Client Shopping

Get
Cart
IPs
Pricing
Service

Registry
Register Order

#1
CQRS Pattern: A microservices design pattern that
separates command (write) and query (read)
operations into distinct models with separate
databases.
#2
Helps Microservices find and talk to each other
without central control.

#3
5 Central Service Registry: A list of all services and
where to find them$
5 Microservices Registration: Services register
themselves with the registry, providing their names
and endpoints.

#4
Large e-commerce website with various
Microservices (e.g., order, payment, shipping,
customer).

#5
Use tools like Consul or Eureka to make and manage
the registry.
#6
Order service registers as "order-service" with an
endpoint like "http://order-service:8080".

#7
: Payment service can look up "order-service" in the
registry to send payment info"
: Shipping service can find "order-service" to
retrieve shipping details.

#8
: Independent Development: Services can be
developed and deployed independently"
: Flexibility: No need to hard-code service
endpoints; dynamic discovery"
: Resilience: Can adjust when things move or
change, making it strong and flexible.
Circuit Breaker Pattern in
Microservices
Think of it like a safety switch for microservices. If one
part breaks down, the switch stops it from affecting
everything else.

#1
Keeps apps running even when a service isn't working
right.

#2
F Circuit Breaker: Acts as a protective barrier
between client and service9
F Monitoring: Keeps an eye on the service to see if
it's working9
F State Control: Can open the circuit to block
requests upon detecting service failures.
#3
Microservice application relies on an unreliable
external service.

#4
4 Detects Unreliability: Monitors the service's
health and identifies failures#
4 Circuit Open: Prevents further requests from
reaching the failing service#
4 Graceful Degradation: Allows the application to
switch to an alternative or fallback service.
#5
Hystrix or Spring Cloud help manage this safety
switch.

#6
1 Resilience: Protects the application from service
disruptions.
1 Continuity: Enables the application to function
despite service failures.
1 Controlled Response: Can switch to another
service smoothly.
API Gateway Pattern in
Microservices
Client Apps Microservices

Catalog DB
API Gateway

Shopping

Web Cart DB

Discount DB

Mobile Ordering DB

#1
A fundamental microservices architecture pattern that
employs an API gateway as a central entry point for all
incoming API requests.
#2
Decouples clients from microservices, simplifying
access and abstracting system complexity.

#3
7 API Gateway: Serves as a proxy between clients
and microservices*
7 Routing: Directs requests to the appropriate
microservice based on the endpoint.

#4
7 Abstraction: Presents a simplified and consistent
API, eliminating the need to remember multiple
microservice addresses*
7 Security & Governance: Enforces access control,
monitors system performance, and enforces
policies.
#5
E-commerce system with microservices for order
management, product catalog, and user
authentication.

#6
> API Gateway acts as a reverse proxy, receiving all
client requests-
> Routes requests based on endpoints (e.g., /orders,
/products) to respective microservices.

#7
> Transformation: Performs request/response
transformation-
> Rate Limiting: Controls request rates-
> Authentication & Authorization: Ensures secure
access-
> Caching: Improves performance with data
caching.
#8
$ Simplification: Provides a unified API for clients,
hiding microservices' internal details
$ Scalability: Facilitates easy scaling and
management of microservices
$ Security: Enhances security and control over
service access
$ Flexibility: Streamlines development, deployment,
and maintenance of microservices-based
applications.`
Event Sourcing in
Microservices
Event Sourcing Pattern
UI
Client
SC Created

Item 1 added Read Database

Item 2 added Consume Masterlized

event View

Item 1 deleted Eventbus Eventual

Consistency
Event
Sourcing
Publish
event
Event Replay
Store Events
Replay

#1
A microservices pattern for persisting and querying
data by capturing all state changes as events,
enabling reconstruction of application state.
#2
Event Logging: Records every state change as an
event, creating a historical log.

#3
E-commerce application example: Events like
OrderPlaced, ShipmentMade, and OrderCanceled.

#4
k Auditability: Provides an auditable log of all
system changesQ
k Scalability: Allows parallel processing of events
for improved scalabilityQ
k Flexibility: Enables changes in data querying and
persistence without altering dataQ
k Fault-tolerance: Immutable events prevent data
modification, ensuring data integrity.
#5
 Complexity: Implementing Event Sourcing
requires careful planning and design
 Querying Overhead: Querying data may be slower
due to event replay; use judiciously.

#6
 Evaluate if Event Sourcing is the right fit for your
application, as alternative solutions may be more
suitable in some cases.
Command Query Responsibility
Segregation (CQRS) Pattern in
Microservices
CQRS Design Pattern

Tables or
Write Database Event
Command Sourcing

Eventbus
Eventual
UI Consistency
Client

Query
Materialized
Read Database View

#1
CQRS Pattern: A microservices design pattern that
separates command (write) and query (read) operations
into distinct models with separate databases.
#2
Distinct Models: Recognizes that models for writing
data differ from models for reading data.

#3
< Command Model: Receives commands, writes to
the database6
< Query Model: Reads from the database, sends
data to clients.

#4
< Performance: Optimizes each model for its
specific task, enhancing system performance6
< Scalability: Allows independent optimization and
scaling of command and query models6
< Simplified Code: Separation of concerns simplifies
the codebase.

#5
E-commerce application with separate models for
writing and reading product information.
#6
 Command Model: Write-optimized, stores data in
a write-optimized database
 Query Model: Read-optimized, stores data in a
read-optimized database.

#7
Models communicate through an event bus or
message queue.

#8
 Complexity: May introduce complexity with
separate models and databases
 Development Effort: Requires additional
development effort to maintain separate models.`

#9
CQRS enhances system scalability, performance, and
maintainability by isolating command and query
operations, but it should be carefully considered for
suitability in each application.
SAGA Pattern in Distributed
Architecture

Service Service Service

Message / Event Message / Event

Local
Local
Local

Transaction Transaction Transaction

#1
A solution for maintaining data consistency in a
distributed architecture without relying on ACID
principles. It allows for committing multiple
compensatory transactions.
#2
 Choreography: No central orchestration; services
execute transactions, publish events, and respond
to events from other services
 Orchestration: Each service performs
transactions, publishes events, and other services
respond to these events to complete their tasks.

#3
Data Consistency: Ensures data consistency across
multiple services without creating tight coupling.

#4
 Complexity: High complexity in designing and
implementing sagas compared to traditional
transactions
 Developer Familiarity: Developers may not be
well-versed in writing sagas as they would with
traditional transactions.
Bulkhead Pattern
#1
A fault tolerance design that isolates elements of an
application into partitions, preventing failure in one
part from affecting others, similar to ship bulkheads.
#2
G In a cloud-based application, excessive load or
service failure can impact all consumers9
G Resource exhaustion may affect consumers and
services, causing cascading failures.
#3
G Partition service instances based on consumer load
and availability requirements9
G Partition consumer resources to prevent resource
exhaustion.
#4
 Limits failure spread
 Maintains some function during issues
 Offers varied service quality.

#5
 Bulkheads structured around connection pools
calling services
 Multiple clients calling a single service with
isolated instances.

#6
 Define partitions by business/tech needs
 Weigh isolation, cost, performance, manageability
 Use retry, circuit breaker, throttling pattern
 Consider VMs, containers, processes for
deployment.
#7

 Separate resources for backend services

 Isolate critical from standard consumers
 Protect against cascading failures.

#8

 May be less resource-efficient

 Added complexity might not be always needed.
 Why

Bosscoder?
1000+ Alumni placed at Top
Product-based companies.

More than 136% hike for every 


2 out of 3 working professional.

Average package of 24LPA.

Explore More