1.

Microservice Architecture

Microservices Architecture (MSA) is an approach where a large application is divided into a suite
of small, autonomous services that are independently deployable and loosely coupled. Each service
maps to a specific business capability and communicates through lightweight protocols like REST
or messaging.

[Link] Computing

Distributed computing refers to a system where processing and data storage is distributed across
multiple devices or systems, rather than being handled by a single central device. In a distributed
system, each device or system has its own processing capabilities and may also store and manage its
own data. These devices or systems work together to perform tasks and share resources, with no
single device serving as the central hub.

[Link] of Microservices from Distributed Computing

Microservices evolved as a refined, business-aligned, loosely coupled form of distributed systems

that solves issues like:

• heavy coupling in distributed objects,

• lack of scalability,

• and complexity in enterprise systems.

[Link] Architecture

Monolithic architecture is a software design methodology that combines all of an application's

components into a single, inseparable unit. Under this architecture, the user interface, business
logic, and data access layers are all created, put into use, and maintained as one, unified unit.

Monolith = single deployable unit where:

• UI layer
 • Business layer

• Data layer
exist in one application and use one shared database.

(Features, Advantages, Disadvantages, Applications)

[Link] JEE concepts relevant to microservices:

i) Loose Coupling and High Cohesion

ii) Separation of Concerns
iii) Independent Deployability

[Link] Patterns:

i) Database per service pattern

Dedicated database for each service:

A database dedicated to one service can’t be accessed by other services. This is one of the reasons
that makes it much easier to scale and understand from a whole end-to-end business aspect.
ii)Saga pattern

The Saga pattern manages distributed transactions across multiple microservices by breaking them
into a sequence of local transactions. If a transaction in the sequence fails, it triggers a series of
compensating transactions to undo the changes made by preceding successful transactions, ensuring
data consistency. This avoids the performance issues.

iii)API gateway pattern

The API Gateway pattern in microservices architecture functions as a single entry point for all client
requests, acting as a reverse proxy that routes requests to the appropriate backend microservices.
This pattern provides a unified and simplified interface to the client, abstracting the complexity of
the underlying microservice architecture.

iv)Aggregator design pattern

An aggregator design pattern is used to collect pieces of data from various microservices and
returns an aggregate for processing. Although similar to the backend-for-frontend (BFF) design
pattern, an aggregator is more generic and not explicitly used for UI.

v) Circuit breaker design pattern

This pattern is usually applied between services that are communicating synchronously. A developer
might decide to utilize the circuit breaker when a service is exhibiting high latency or is completely
unresponsive. The utility here is that failure across multiple systems is prevented when a single
microservice is unresponsive. Therefore, calls won’t be piling up and using the system resources,
which could cause significant delays within the app or even a string of service failures.

vi) Command query responsibility segregation (CQRS)

The Command Query Responsibility Segregation (CQRS) pattern in microservices is an

architectural approach that separates the responsibilities of handling commands (write operations)
and queries (read operations) into distinct models, and often, distinct data stores.

vii) Event sourcing(write content related to kafka)

The event sourcing design pattern is used in microservices when a developer wants to capture all
changes in an entity’s state. Using event stores like Kafka or alternatives will help keep track of
event changes and can even function as a message broker. A message broker helps with the
communication between different microservices, monitoring messages and ensuring communication
is reliable and stable. To facilitate this function, the event sourcing pattern stores a series of state-
changing events and can reconstruct the current state by replaying the occurrences of an entity

viii) Asynchronous messaging

If a service doesn’t need to wait for a response and can continue running its code post-failure,
asynchronous messaging can be used. Using this design pattern, microservices can communicate in
a way that’s fast and responsive. Sometimes this pattern is referred to as event-driven
communication.

ix) Strangler :( used to convert monolithic to microservice)

Developers mostly use the strangler design pattern to incrementally transform a monolith
application to microservices. This is accomplished by replacing old functionality with a new service
— and, consequently, this is how the pattern receives its name. Once the new service is ready to be
executed, the old service is “strangled” so the new one can take over.

x) Decomposition Pettern:

Decomposition design patterns are used to break a monolithic application into smaller, more
manageable microservices.

[Link] Architecture & Implementation in Microservices

Defn:

REST, or Representational State Transfer, is a widely adopted architectural style for designing
networked applications, particularly well-suited for microservices due to its simplicity, flexibility,
and scalability.

REST Architecture Principles:

i) Client-Server: A clear separation of concerns exists between the client and the server, allowing
independent development and evolution.
ii) Stateless: Each request from a client to a server must contain all the information necessary to
understand the request. The server does not store any client context between requests.
Iii) Cacheable: Responses from the server should be explicitly or implicitly labeled as cacheable or
non-cacheable to improve performance and network efficiency.
iv) Layered System: Components can be organized in hierarchical layers, where each layer interacts
only with its immediate neighbors.

REST Implementation in Microservices:

i) Resource-Oriented APIs: Microservices expose their functionalities as resources, which are

accessed and manipulated using standard HTTP methods (GET, POST, PUT, DELETE, PATCH)
corresponding to CRUD operations.
ii) Standardized Communication: RESTful APIs leverage HTTP as the communication protocol,
making them easily consumable by various clients and other microservices.
Iii) Data Formats: JSON is the most common format for exchanging data between RESTful
microservices, though XML or other formats can also be used.
iv) API Gateway: An API Gateway can be used in a microservices architecture to provide a single
entry point for clients, handling routing, authentication, and other cross-cutting concerns.
Service Discovery: Mechanisms like client-side or server-side discovery are used to locate and
connect to available microservice instances.
v) Loose Coupling: REST promotes loose coupling between services, allowing independent
development, deployment, and scaling of individual microservices.
vi) OpenAPI Specification: Documenting RESTful APIs using specifications like OpenAPI
provides a clear contract for how services are expected to communicate, facilitating development
and integration.
Security in REST

i)OAuth2
ii)JWT Tokens
iii)API Keys
iv) HTTPS
v) Rate limiting
vi) Input validation

8) SpringBoot for Microservices

i. Introduction

Spring Boot simplifies Java-based microservices using:

[Link]-configurations

[Link] servers

[Link] dependencies

ii. REST Controller

@RestController
@GetMapping / @PostMapping

iii. Error Handling

@ControllerAdvice

@ExceptionHandler

iv). Validation

@Valid

@NotNull, @Size, @Email

v. REST API Client

RestTemplate (deprecated)

WebClient (reactive)

vi. Spring for Microservices

Spring Cloud
Eureka Server
API Gateway
Config Server
Load Balancing
9. Messaging in Microservices

1. Introduction

In microservice architecture, services must communicate reliably. This communication can be:

Synchronous (REST/gRPC)

Asynchronous (Messaging systems)

Kafka provides high-performance, distributed, fault-tolerant messaging, enabling services to

exchange data without knowing each other’s internal logic.

2. Need for Messaging in Microservices

Loose Coupling – Services don't directly depend on each other.

Asynchronous Processing – Heavy tasks processed in background.

Event-Driven Architecture (EDA) – Services emit/consume events.

Improved Scalability – Message queues handle high throughput.

Resilience – If one service is down, messages are stored safely.

3. Kafka Architecture Explained (write diagrams ...expln with examples as studied for apache
kafka)

Kafka consists of the following components:

a) Topics

A topic is a category/channel where messages are stored.

Example:

“orders”

“payments”

Messages are appended sequentially.

b) Partitions

Topics are divided into partitions for:

horizontal scaling

parallel processing

Each partition is an ordered, immutable log of events.

Example: topic “orders” → partition-0, partition-1, partition-2

c) Offset

Each event is assigned a unique offset inside a partition.

Consumers use offsets to track which messages they've processed.

d) Producer

Producers publish messages into Kafka topics.

Features:

asynchronous sending

batch processing

partitioning strategies (round-robin / key-based)

e) Consumer

Consumers read messages from topics at their own pace.

A Consumer Group ensures:

parallel consumption

load balancing

Each partition is consumed by only one consumer in a group.

f) Kafka Broker

A broker is a Kafka server that stores partitions.

A Kafka cluster contains many brokers.

g) Cluster

A Kafka cluster = multiple brokers working together.

Advantages:

fault tolerance

replication

horizontal scalability

h) Replication

Each partition is replicated across multiple brokers.

Replication ensures:

high availability

fault tolerance

durability

Example: Replication factor = 3

→ 1 leader + 2 followers

4. Spring Boot Kafka Integration

write dependency
then...write producer and consumer yaml code seperately

if page not filled...write adv and disadv

10) Security , validation and exception handling

security(authentication, authorization, data transporation security and api gateway security)

validation (bean validation, controller-level validation)

exception handling(kadhai from previously learnt ones..and also write some about error codes lyk
400 – Bad Request

401 – Unauthorized

404 – Not Found

500 – Internal Server Error)

11) Service to Service Communication in microservices