1.

Decomposition Patterns
Business Capability Split services
based on business domains (e.g., Order, Payment, Inventory).
Subdomain Driven Uses Domain-Driven
Design (DDD) to create microservices based on subdomains.
Strangler Fig Incrementally
migrates a monolithic system to microservices.

2. Communication Patterns
API Gateway Centralized entry
point for clients, handling authentication, routing, and aggregation.
Backend for Frontend (BFF) Custom API gateways for
different frontend clients (web, mobile).
Service Registry & Discovery Services dynamically register
themselves and discover each other (e.g., Eureka, Consul).
Circuit Breaker Prevents cascading
failures by stopping requests to failing services (e.g., Resilience4j, Hystrix).

3. Data Management Patterns

Database per Service Each microservice has
its own database to avoid tight coupling.
Saga Pattern Manages
distributed transactions using a sequence of local transactions.
CQRS (Command Query Responsibility Segregation) Separates read and write models for
better scalability.
Event Sourcing Stores changes as
a sequence of events instead of current state.

4. Resilience & Deployment Patterns

Bulkhead Isolates failures
to prevent service-wide crashes.
Sidecar Attaches
helper components (e.g., logging, monitoring) alongside a microservice.
Blue-Green Deployment Deploys new versions
without downtime.
Canary Deployment Releases new features
gradually to a subset of users.

** Circuit Breaker
Prevents cascading failures by stopping calls to a failing service.
Works like an electrical circuit breaker: If failures exceed a threshold, it
"trips" and blocks further calls.
After some time, it allows a few test calls before fully resuming.

States of Circuit Breaker

State Behavior When it Happens?
Closed Requests pass normally ✅ Service is healthy
Open Requests are blocked ❌ Failure rate exceeds threshold
Half-Open Limited requests pass 🟡 After a cooldown period, to test recovery

1] Initially, the Circuit Breaker is Closed → Calls go through normally.

2] If failures exceed 50% in 5 calls → Circuit Breaker Opens → Calls fail
immediately.
3] After 10s, it moves to Half-Open → Allows a few test calls.
4] If test calls succeed → Back to Closed. If they fail → Stays Open.

** API Gateway
An API Gateway is a single entry point for client requests that routes them
to appropriate microservices. It acts as a reverse proxy, handling:
✅ Routing – Directs requests to the correct microservice.
✅ Security – Authenticates & authorizes users.
✅ Load Balancing – Distributes traffic efficiently.
✅ Rate Limiting – Controls request limits to prevent abuse.
✅ Logging & Monitoring – Tracks API usage & performance.

✅ Single Entry Point – Clients don’t need to know microservices’ internal

URLs.
✅ Security – Centralized authentication & authorization.
✅ Performance – Load balancing, caching, and rate limiting improve
efficiency.
✅ Decoupling – Frontend is independent of backend microservices.

Problems Without API Gateway

🚫 Client Complexity – The frontend must manage multiple service URLs.

🚫 Security Issues – Each microservice must handle authentication separately.
🚫 Hard to Scale – Adding new services requires frontend changes.
🚫 No Centralized Monitoring – Hard to track API usage and failures.

** Service registry and Discovery

A Service Registry serves as a centralized database or directory where
information about available services and their locations is stored and maintained.
Self-Registration:
The service itself registers with and deregisters from the registry.
Example: A microservice sends a request to register itself on startup.
Third-Party Registration:
A separate Service Manager registers and deregisters services.
Ensures better resilience by monitoring service health and handling
failures gracefully.

Service Discovery is the mechanism that allows microservices to locate and

interact dynamically without hardcoded IPs or URLs.
Client-Side Discovery
The client queries the service registry, picks a service instance, and
connects directly. Netflix Eureka, Consul
Server-Side Discovery
A load balancer or API Gateway fetches service details from the
registry and routes the request. AWS Elastic Load Balancer

Health Checks: Ensure only healthy services are available. If a service

fails, it is removed from the registry.
Load Balancing: Evenly distributes traffic among available service instances.
Can be client-side (Ribbon) or server-side (Eureka, Consul, AWS ELB).

✅ Scalability – New services can be added or removed without downtime.

✅ Fault Tolerance – If a service instance fails, traffic is rerouted to other
instances.
✅ Simplifies Management – No need to manually track service URLs.

** Test-Driven Development(TDD)
Test-Driven Development (TDD) is a software development strategy that
involves writing tests before writing code.
Test-driven development (TDD) is a way of writing code that involves writing
an automated unit-level test case that fails,
then writing just enough code to make the test pass, then refactoring both
the test code and the production code, then repeating with another new test case.

Benefits of TDD
Early bug detection: TDD helps developers identify issues early in the
development process.
Improved design quality: TDD encourages developers to write clean,
maintainable, and modular code.
Faster development: TDD's fast feedback loop and automated testing
allow for faster development iterations.
Improved collaboration: TDD's shared tests help team members
communicate and collaborate more effectively.
Increased confidence: TDD helps developers be more confident in their
code.

TDD challenges
Increased Code Volume: Using TDD means writing extra code for tests
cases , which can make the overall codebase larger and more Unstructured.
False Security from Tests: Passing tests will make the developers think
the code is safer only for assuming purpose.

** Domain-Driven Design (DDD)

Domain-Driven Design (DDD) is a software design approach that focuses on
structuring applications around business domains rather than just technical layers.
It promotes collaboration between developers and domain experts to create
software that reflects real-world business logic.

Key Principles of DDD -

Ubiquitous Language – Business and technical teams use the same
terminology(entity,value object, aggregate, repository, service, factory).
Bounded Contexts – Each domain (e.g., Order, Payment, Inventory) is
independent.
Aggregate Root – Only the root entity (e.g., Order) controls access to
child entities (OrderItem).
Separation of Concerns – Business logic is separate from infrastructure
code.

** Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) is a software development approach that
extends Test-Driven Development (TDD) by focusing on business behavior rather than
just unit tests.
It encourages collaboration between developers, testers, and business
stakeholders using a common language (Given-When-Then format).

✅Improves Communication – Developers, testers, and business analysts use

natural language to describe application behavior.
✅Ensures Business Alignment – Tests are written based on real user
expectations.
✅Automates Functional Testing – Can be used with tools like Cucumber (Java),
SpecFlow (.NET), JBehave, Behave (Python).

Key Differences Between BDD and TDD

Aspect BDD (Behavior-Driven Development) TDD (Test-Driven
Development)
Focus Business behavior Code correctness
Written By Developers, Testers, Business Analysts Developers
Test Format Given-When-Then (Gherkin syntax) Unit tests (JUnit, Mockito)
Best For Functional & UI testing Backend logic & API
testing
Tools Used Cucumber, SpecFlow, JBehave JUnit, TestNG, Mockito

𝗦𝗜𝗡𝗚𝗟𝗘 𝗥𝗘𝗦𝗣𝗢𝗡𝗦𝗜𝗕𝗜𝗟𝗜𝗧𝗬 𝗣𝗥𝗜𝗡𝗖𝗜𝗣𝗟𝗘 (SRP): -> Each class should focus on a single
responsibility or task, making the system easier to maintain and modify.

𝗢𝗣𝗘𝗡/𝗖𝗟𝗢𝗦𝗘𝗗 𝗣𝗥𝗜𝗡𝗖𝗜𝗣𝗟𝗘 (OCP): -> Classes should be open for extension but closed
for modification. You can add new features without changing existing code.

𝗟𝗜𝗦𝗞𝗢𝗩 𝗦𝗨𝗕𝗦𝗧𝗜𝗧𝗨𝗧𝗜𝗢𝗡 𝗣𝗥𝗜𝗡𝗖𝗜𝗣𝗟𝗘 (LSP): -> Subclasses should be able to replace

their parent classes without breaking functionality.

𝗜𝗡𝗧𝗘𝗥𝗙𝗔𝗖𝗘 𝗦𝗘𝗚𝗥𝗘𝗚𝗔𝗧𝗜𝗢𝗡 𝗣𝗥𝗜𝗡𝗖𝗜𝗣𝗟𝗘 (ISP): -> Don’t force classes to implement

methods they don't need. Smaller, more focused interfaces work better.

𝗗𝗘𝗣𝗘𝗡𝗗𝗘𝗡𝗖𝗬 𝗜𝗡𝗩𝗘𝗥𝗦𝗜𝗢𝗡 𝗣𝗥𝗜𝗡𝗖𝗜𝗣𝗟𝗘 (DIP): -> High-level modules should not depend
on low-level modules. Both should depend on abstractions.