Pattern Pattern

Description Example Use Case

Type Name
Ensures a class has only Configuration
Creation
Singleton one instance and provides a settings
al
global point of access. management.
Defines an interface for
GUI frameworks to
Factory creating an object but
create different
Method allows subclasses to alter
button types.
the type of created objects.
Provides an interface for
creating families of related Creating UI elements
Abstract
or dependent objects across different
Factory
without specifying their operating systems.
concrete classes.
Separates the construction
of a complex object from its
Building a complex
representation, allowing the
Builder object like a User
same construction process
with optional fields.
to create different
representations.
Creates new objects by Cloning objects when
Prototype copying an existing object, object creation is
known as the prototype. costly.
Allows incompatible
interfaces to work together
Integrating a legacy
Structur by converting the interface
Adapter system with a new
al of a class into another
application.
interface that a client
expects.
Separating the
Separates an interface from
abstraction of a
its implementation, allowing
Bridge shape from its
the two to vary
drawing
independently.
implementation.
Composes objects into tree Representing a file
Composite structures to represent part- system with files and
whole hierarchies. directories.
Adds additional
Adding scrolling
responsibilities to an object
Decorator capability to a
dynamically without
window.
modifying its structure.
Provides a simplified Simplifying
Facade interface to a complex interactions with a
subsystem. complex library.
Flyweight Reduces memory usage by Efficiently managing
sharing common parts of a large number of
state between multiple similar objects, like
objects. characters in a
Pattern Pattern
Description Example Use Case
Type Name
game.
Enables selecting an
algorithm's behavior at
Implementing
Behavior runtime by defining a family
Strategy different sorting
al of algorithms, encapsulating
algorithms.
each one, and making them
interchangeable.
Defines a one-to-many
dependency between Event handling
Observer objects so that when one systems, such as in
object changes state, all its GUI applications.
dependents are notified.
Encapsulates a request as
Implementing
an object, allowing for
undo/redo
Command parameterization of clients
functionality in
with queues, requests, and
applications.
operations.
Allows an object to alter its
Implementing a state
behavior when its internal
State machine, like a
state changes, appearing to
traffic light.
change its class.
Passes a request along a
Chain of chain of handlers, where Implementing event
Responsibilit each handler can either handling in GUI
y process the request or pass frameworks.
it to the next handler.
Defining the outline
Defines the skeleton of an
for an algorithm
Template algorithm in a method,
where subclasses
Method deferring some steps to
implement specific
subclasses.
steps.
Allows adding new Performing
operations to existing object operations on
Visitor
structures without elements of a
modifying them. composite structure.

1. API Gateway Pattern

 Description: An API gateway acts as a single entry point for client
requests to various microservices. It can handle requests, route
them to appropriate services, and aggregate responses.
 Benefits: Simplifies client interactions, reduces the number of
requests that reach the microservices, and can handle cross-cutting
concerns like authentication, logging, and rate limiting.
2. Service Discovery Pattern
  Description: In microservices, services need to locate each other
dynamically. Service discovery can be client-side or server-side.
o Client-Side Discovery: The client is responsible for
determining the network locations of available service
instances.
o Server-Side Discovery: A service registry holds the
locations of available services, and the API gateway or load
balancer queries this registry to route requests.
 Tools: Eureka, Consul, and Zookeeper.
3. Circuit Breaker Pattern
 Description: This pattern prevents a service from repeatedly trying
to execute an operation that is likely to fail. It helps to improve
system stability and resilience.
 Implementation: If a service call fails repeatedly, the circuit
breaker trips, and requests are not sent for a predefined period.
After that, it allows a limited number of requests to check if the
service is back online.
 Tools: Hystrix, Resilience4j.
4. Database per Service Pattern
 Description: Each microservice manages its own database,
ensuring loose coupling and allowing teams to choose the best
database technology for their needs.
 Benefits: Reduces the risk of database contention and allows for
independent evolution of data models.
5. Event Sourcing Pattern
 Description: Instead of storing the current state of an entity, this
pattern stores all the changes (events) that have occurred. The
current state can be reconstructed from these events.
 Benefits: Provides a complete audit trail and allows for complex
event processing.
6. CQRS (Command Query Responsibility Segregation) Pattern
 Description: This pattern separates the responsibility of reading
data (queries) from updating data (commands). It allows for
optimization of read and write operations.
 Benefits: Enhances performance, scalability, and security by
allowing different models for reading and writing data.
7. SAGA Pattern
 Description: A distributed transaction pattern that ensures data
consistency across microservices by coordinating a series of local
transactions.
 Types:
o Choreography: Each service produces and listens to events,
orchestrating the process through events.
o Orchestration: A central coordinator directs the saga,
managing the sequence of local transactions.
 Benefits: Helps manage distributed transactions without the
complexities of two-phase commit.
8. Sidecar Pattern
  Description: This pattern involves deploying a helper service
alongside a microservice to handle cross-cutting concerns like
logging, monitoring, or service discovery.
 Benefits: Enables independent deployment of services while
abstracting away infrastructure concerns.
9. Strangler Fig Pattern
 Description: This pattern is used to gradually replace a legacy
system with a new microservices-based architecture. New features
are built as microservices, while existing features are gradually
refactored.
 Benefits: Reduces risk by allowing gradual migration without a
complete rewrite.
10. Backend for Frontend (BFF) Pattern
 Description: This pattern involves creating separate backend
services tailored to specific front-end applications (e.g., mobile vs.
web). Each BFF can optimize the data and functionality it provides.
 Benefits: Enhances performance and simplifies the interaction
between clients and microservices.

Principle Description
S — Single A class should have only one reason to change,
Responsibility Principle meaning it should only have one job or
(SRP) responsibility.
Software entities (classes, modules, functions)
O — Open/Closed
should be open for extension but closed for
Principle (OCP)
modification.
Subtypes must be substitutable for their base
L — Liskov Substitution
types without altering the correctness of the
Principle (LSP)
program.
I — Interface Clients should not be forced to depend on
Segregation Principle interfaces they do not use; create smaller, specific
(ISP) interfaces.
D — Dependency High-level modules should not depend on low-
Inversion Principle level modules; both should depend on
(DIP) abstractions (interfaces).

NFR
Description Key Considerations
Category
Ability to handle increased Horizontal scaling, service
Scalability
load by adding resources. replication, load balancing.
Response time and Asynchronous processing,
Performance throughput of the system caching, efficient data
under various conditions. access.
Availability System uptime and Redundancy, failover
NFR
Description Key Considerations
Category
reliability, minimizing
mechanisms, health checks.
downtime.
Ability to recover from
Circuit breakers, retries,
Resilience failures and maintain service
graceful degradation.
continuity.
Protecting data and services
Authentication, authorization,
Security from unauthorized access
data encryption, secure APIs.
and breaches.
Modular design, clear
Maintainabil Ease of making changes and
documentation, automated
ity updates to the system.
testing.
Observabilit Ability to monitor and trace Logging, monitoring tools,
y requests across services. distributed tracing.
Ability of different services to
Interoperabi Standardized APIs, data
work together, potentially
lity formats (e.g., JSON, XML).
across platforms.
Ease of adapting to changes
Use of containers,
Flexibility in requirements or
microservice independence.
technologies.
CI/CD pipelines, automated
Deployabilit Ease and speed of deploying
deployments, blue-green
y new versions of services.
deployments.

Factor Description Key Considerations

A single codebase tracked in Use Git or another
1. Codebase version control, with multiple version control system
deployments. for tracking.
2. Explicitly declare and isolate Use tools like Maven,
Dependencie dependencies using a Gradle, or npm to
s dependency manager. manage dependencies.
Store configuration in the Use environment
3. Config environment, separate from the variables for
codebase. configuration settings.
Treat backing services
Use service URLs to
4. Backing (databases, queues) as
reference external
Services attached resources that can be
services.
swapped easily.
Strictly separate the build,
5. Build, Automate build and
release, and run stages of the
Release, Run deployment processes.
app.
Ensure processes can
Execute the app as one or more
6. Processes start and stop
stateless processes.
independently.
7. Port Export services via port binding, Use HTTP servers that
Factor Description Key Considerations
listen on ports to serve
Binding making the app self-contained.
requests.
Scale out by running multiple Use process management
8.
processes to handle increased tools for scaling (e.g.,
Concurrency
load. Docker).
Implement signal
9. Maximize robustness with fast
handling and cleanup
Disposability startup and graceful shutdown.
procedures.
Keep development, staging, and Use containers or similar
10. Dev/Prod
production environments as tools for environment
Parity
similar as possible. parity.
Treat logs as event streams and Use logging frameworks
11. Logs aggregate them in a centralized and log aggregation
location. services.
Run administrative or Use scripts or command-
12. Admin
management tasks as one-off line tools for
Processes
processes. maintenance tasks.

Property Description
Every read receives the most recent write or an error. All
C - Consistency
nodes see the same data at the same time.
Every request (read or write) receives a response, without
A - Availability
guarantee that it contains the most recent data.
P - Partition The system continues to operate despite network
Tolerance partitions or communication failures between nodes.

Trade-offs: According to the CAP theorem, you can only achieve two out
of the three properties at any given time. This leads to trade-offs in
system design.
Design Implications:
 CP Systems: Prioritize Consistency and Partition Tolerance (e.g.,
HBase, MongoDB in certain configurations).
 AP Systems: Prioritize Availability and Partition Tolerance (e.g.,
Cassandra, DynamoDB).
Real-World Applications: Understanding the CAP theorem helps
architects choose the right database and design patterns based on
application requirements, such as financial systems (favoring consistency)
versus social media platforms (favoring availability).
Deployment Strategies

Blue-Green Deployment - Two identical environments (blue and green)

are maintained. One environment (e.g., blue) runs the current version,
while the other (e.g., green) runs the new version

Canary Deployment: A small subset of users is directed to the new

version while the majority continues to use the old version.

Rolling Deployment: The new version is incrementally rolled out to

instances of the service without downtime.

Circuit Breaker:
When a microservice depends on an external API that might be
experiencing downtime, the Circuit Breaker can be used to stop sending
requests to that API and provide a fallback response
 The Circuit Breaker pattern prevents a service from repeatedly
trying to execute an operation that's likely to fail, thereby avoiding
resource exhaustion and allowing the system to recover.
 Closed, OPen, Half-Open : State

Fault Tolerance:
Fault Tolerance refers to the ability of a system to continue functioning
correctly even in the presence of failures.
 Redundancy: Duplication of critical components or services to
ensure availability.
 Graceful Degradation: The system continues to operate in a
reduced capacity rather than failing completely.
 Fallback Mechanisms: Providing alternative responses when a
service fails (e.g., serving cached data).
Architecture Descripti Key Use
Pattern on Cases
A single unified unit where all Simple applications,
Monolithic
components are interconnected startups, and small
Architecture
and interdependent. teams.
Large applications,
Decomposes applications into
Microservices continuous
small, loosely coupled services
Architecture deployment,
that communicate over APIs.
scalability.
Uses events to trigger and
Real-time applications,
Event-Driven communicate between
complex workflows, and
Architecture decoupled services or
asynchronous systems.
components.
Organizes the system into layers,
Enterprise applications,
Layered each with a specific role (e.g.,
where separation of
Architecture presentation, business logic, data
concerns is crucial.
access).
Separates the client and server Web applications,
Client-Server
roles, allowing for distributed database systems, and
Architecture
processing and resource sharing. network services.
Service-
Builds applications as a Enterprise integrations
Oriented
collection of services that and complex business
Architecture
communicate over a network. processes.
(SOA)
Allows developers to build and run Event-driven
Serverless
applications without managing applications, APIs, and
Architecture
servers, using cloud services. microservices.
Domain- Focuses on modeling software Complex business
Driven based on the business domain applications with rich
Design (DDD) and its logic. domain models.
Distributes processing and High-traffic
Space-Based
storage across multiple nodes to applications and large-
Architecture
handle load and scale. scale systems.
Broker Mediates communication between Messaging systems,
Architectur components through a broker, integration platforms,
e enabling loose coupling. and distributed systems.
Structures the system as a
Data processing
Pipeline series of processing steps or
applications, ETL systems,
Architecture stages, often for data
and batch processing.
processing.
Hexagonal Emphasizes the separation of
Testable applications
Architecture the core logic from external
and those needing
(Ports and agents through ports and
flexible interfaces.
Adapters) adapters.
Java 21 Features :: 15 JEPs (JDK Enhancement Proposals)

String Templates (Preview)  –enable-preview flag to your compiler

args

Aspect Example:
Spring Boot Document:

implementation 'org.springdoc:springdoc-openapi-ui:1.6.14' // Check for

the latest version

springdoc.show-actuator=true
springdoc.use-management-port=true
management.endpoints.web.exposure.include=openapi, swagger-ui
implementation 'io.micrometer:micrometer-core'
implementation 'io.micrometer:micrometer-registry-prometheus'
APIGEE / Kong
Istio/Kiolo Linked