Micro-Services Design Patterns

1.CQRS

Command and Query Responsibility Segregation.

As definition, query that any method return values, while command that any method mutates states.

Segregate operations that read data from operations from that update data by using separate interfaces/services, one interface for reading and another one for writing.

This pattern can maximize performance, scalability, and security; support evolution of the system over time through higher flexibility; and prevent update commands from causing merge conflicts at the domain level.

It keeps SRP, by different implementation for each functionality, that simplify implementation, and increase maintainability, and deployment effort.

In traditional architectures, the same data model is used to query and update a database. That's simple and works well for basic CRUD operations. In more complex applications, however, this approach can become unwieldy.  

Benefits of CQRS include:

• Independent scaling. CQRS allows the read and write workloads to scale independently, and may result in fewer lock contentions.

• Optimized data schemas. The read side can use a schema that is optimized for queries, while the write side uses a schema that is optimized for updates.

• Security. It's easier to ensure that only the right domain entities are performing writes on the data.

• Separation of concerns. Segregating the read and write sides can result in more maintainable and flexible models. Most of the complex business logic goes into the write model. The read model can be relatively simple.

• Simpler queries. The application can avoid complex joins when querying by storing a materialized view in the read database.

Use Case:

 Imagine you have ecosystem, that has 1500 reports, which includes:

• Daily consolidated reports

• Monthly consolidated reports

• Yearly consolidated reports

• Search reports for with different intervals

What will be the impact in case of building these reports on the production(primary) database?!!! 

Implementation Approach:

1. Segregate between the Operation database and reporting database

2. Operation database to be the primary one

3. Reporting and analytics database to be the DR one

8.External Configuration design pattern

Service will be published in different environments, dev, test, staging, and production, also, connecting to test database, and also production environment.

So, Moving configuration information out of the application deployment package to a centralized location.

This pattern can provide opportunities for easier management and control of configuration data, and for sharing configuration data across applications and application instances

It's also strongly related to runtime reconfiguration pattern, that decrease the shutdown time for the solution, specially the sensitive business domains like banking and airlines.

Will be valid for running servers, databases, storage, and integration.

This issue can also touch the Runtime reconfiguration design pattern, and both complement each others.

The important hints here are:

1. You are not living alone, you are in the context of ecosystem, so you need to know what surrounding you, at the ecosystem level, and at the friend modules

2. You need to unify the configuration at modules level

3. You need single responsibility for the configuration areas

4. You need the facility to reconfigure the solution in the runtime

So, Considering this pattern will lead to abstracted model for the external configuration, the prevent code injection with information that can be changed in the future, due to business need or customer business line.

The opposite pyramid represents the required co-worker design patterns to implement external configuration design pattern:

1. Runtime reconfiguration: to prevent restarting the services.

2. Cache aside: to prevent revisiting the DM

What To configure:

As a rule, you can configure anything that subject for change, as example:

1. Design Theme

2. Module

3. Features

4. Standards

5. Screens

6. Views

7. Filters

8. Reports/analytics

9. Business rules

10. Equations

11. Encryption keys

12. Integration touch points

13. Database settings

9.Federated identity design pattern

Delegate authentication to an external identity provider. This pattern can simplify development, minimize the requirement for user administration, and improve the user experience of the application.

Organizations can select its idp(identity provider) according to installed solutions in order to have single sign on process.

This model is often called claims-based access control. Applications and services authorize access to features and functionality based on the claims contained in the token. 

Sample of identity providers;

• Google, Facebook. Apple, Microsoft and Amazon Web Services (AWS)

• Identity management solutions, like Keycloak, which support social media authentication, 2-Way-Authentication, OTP, and groups management.

When To Use it?

1. Single sign-on in the enterprise 

2. Federated identity with multiple partners 

3. Federated identity in SaaS applications 

14. Publisher subscriber, for EDA, IN Addition to Competing Consumer Pattern 

Enable an application to announce events to multiple interested consumers asynchronously, without coupling the senders to the receivers.

This pattern is the evolution of EDA from the desktop and web applications, but the events here due to external components, and frameworks, like KAFKA and AMQ. 

In cloud-based and distributed applications, components of the system often need to provide information to other components as events happen.

Asynchronous messaging is an effective way to:

• decouple senders from consumers

• Avoid blocking the sender to wait for a response

However, using a dedicated message queue for each consumer does not effectively scale to many consumers. Also, some of the consumers might be interested in only a subset of the information. 

So: How can the sender announce events to all interested consumers without knowing their identities?

Introducing asynchronous messaging subsystem that includes the following:

•  An input messaging channel used by the sender. The sender packages events into messages, using a known message format, and sends these messages via the input channel.

• Sender is publisher, consumer is subscriber.

• A mechanism for copying each message from the input channel to the output channels for all subscribers interested in that message. 

The benefits of this pattern in to remove the complexity from the solution, and the coupling between components, in order to resolve the hexagonal architecture pattern.

So it's too important to the team to understand what's behind the pattern in order to utilize it.

What is Apache Kafka? 

Apache Kafka is a distributed streaming platform that enables users to publish and subscribe to streams of records, store streams of records, and process them as they occur. Kafka is most notably used for building real-time streaming data pipelines and applications and is run as a cluster on one or more servers that can span more than one data center. The Kafka cluster stores streams of records in categories called topics, and each record consists of a key, a value, and a timestamp.

Key characteristics of Apache Kafka include:

• Event-based data flows as a foundation for (near) real-time and batch processing.

• Scalable central nervous system for events between any number of sources and sinks. Central does not mean one or two big boxes in the middle but a scalable, distributed infrastructure, built by design for zero downtime, handling the failure of nodes and networks and rolling upgrades.

• Integrability of any kind of application and system since technology does not matter. This enables you to connect anything: programming language, APIs like REST, open standards, proprietary tools and legacy applications.

• Distributed storage because there is a lot of complexity behind this and a streaming platform simply has it built-in. This allows you to store the state of a microservice instead of requiring a separate database, for example.

What is an Enterprise Service Bus (ESB)? ESB Definition

An Enterprise Service Bus (ESB) is an architecture that includes a set of rules and principles for integrating applications together. These are specific integration tooling type. However, vendors who offer these solutions vary greatly in their offerings. The core concept of an ESB is that they enable application integration by putting a communication “bus” between them that lets the applications talk to the bus. This process provides a way for the tool to decouple systems from one another so they can communicate “freely.”

Apache Kafka vs. Enterprise Service Bus (ESB); What’s the Difference?

Apache Kafka and its ecosystem is designed as a distributed architecture with many smart features built-in to allow high throughput, high scalability, fault tolerance, and failover. Enterprise can integrate Kafka with ESB and ETL tools if they need specific features for specific legacy integration. An ESB or ETL process can be a source or sink to Apache Kafka like any other Kafka producer or consumer API. Currently, most of the top-rated integration tools also have a Kafka connector because the market drives them this way.

In Azure, We have Azure Service Bus, as enterprise service bus, fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace). Service Bus is used to decouple applications and services from each other, providing the following benefits:

• Load-balancing work across competing workers

• Safely routing and transferring data and control across service and application boundaries

• Coordinating transactional work that requires a high-degree of reliability

Azure Service Bus is the same as Kafka, Which has the following features:

• Messaging. Transfer business data, such as sales or purchase orders, journals, or inventory movements.

• Decouple applications. Improve reliability and scalability of applications and services. Producer and consumer don't have to be online or readily available at the same time. The load is leveled such that traffic spikes don't overtax a service.

• Load balancing. Allow for multiple competing consumers to read from a queue at the same time, each safely obtaining exclusive ownership to specific messages.

• Topics and subscriptions. Enable 1:n relationships between publishers and subscribers, allowing subscribers to select particular messages from a published message stream.

• Transactions

• Message sessions

EDA Using KAFKA and Competing consumers design pattern

Enable multiple concurrent consumers to process messages received on the same messaging channel.

With multiple concurrent consumers, a system can process multiple messages concurrently to optimize throughput, to improve reliability, scalability and availability, and to balance the workload.

This can be achieved using message bus, like RabbitMQ and Azure message queue.

So: You are using Kafka to buffer the Queue by the producers, not to directly call, and the consumed by the consumers, to take from the buffer according dot FIFO approach.

Related pattern is the priority queue to prioritize the messages. 

SAGA Types: 

1. Choreography: Using message broker to send messages across all services, which increase the complexity of the communication between micro-services. and destroy the responsibility of each service .

the services choreograph the workflow among themselves without depending on an orchestrator or having direct communication between them.

When to use: Used in independent microservices, that can listen to external events, with full enabling to rollback status and data model changes.

2. Orchestrator : Which encapsulation of the responsibilities take place by one micro-service, that has well-understanding about the workflow, and distribute communication correctly according to business workflow, It's more suitable for large scale solutions, that your have clear understanding and responsibilities about both the business and micro-services responsibilities

When to use: Used when you have journey manager(orchestrator) that encapsulate the flow, and status of the behavior, which meet the largescale business scope, and support different micros-services design patterns.

19. Anti corruption layer

Anti corruption layer = 

Integration Mapping Layer for Non/Near semantics

The Context of this design pattern is migration between two different solutions, which should be un-touchable till the end of the migration.

Isolate the different subsystems by placing an anti-corruption layer between them. 

This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach.

Implementation Approaches: 

• Timestamp or version columns: This is a CDC method best suited for data tables. Whenever a table row is updated, the timestamp or version column is automatically updated, too. CDC processes will periodically query data tables and pin-point changes by comparing versions or timestamps.

• Change tracking in database engines: Some contemporary database systems have built-in change-tracking mechanisms. One such example is Microsoft SQL Server. The feature records changes to tables, a suitable method for tracking and capturing changes within the database engine.

• Automation tools for Realtime Based: Which is connected to EDA approach, as We mentioned in publisher subscriber design pattern, like  Debezium

Drawbacks

It may have negative impact by the following:

1. Latency

2. Additional development overheads

3. Wrong implementation, by mixing ignoring the application of Strangler Pattern, and go forward for reforming the solution.

Approaches:

1. Sunset: You will close the old solution, while you are migrating

2. Co-Working: Solution will be running together, which can require tool like debezium.

22.Health Endpoint Monitoring

Implement functional checks within an application that external tools can access through exposed endpoints at regular intervals. This pattern can help to verify that applications and services are performing correctly.

It's a good practice, and often a business requirement, to monitor web applications and back-end services, to ensure they're available and performing correctly. However, it's sometimes more difficult to monitor services running in the cloud than it is to monitor on-premises services. For example, you don't have full control of the hosting environment, and the services typically depend on other services provided by platform vendors and others.

It can be against specific key metrics to check the solution service behavior over time.

Solution

Implement health monitoring by sending requests to an endpoint on your application. The application should perform the necessary checks and then return an indication of its status.

A health monitoring check typically combines two factors:

• The checks (if any) that the application or service performs in response to the request to the health verification endpoint

• The analysis of the results by the tool or framework that performs the health verification check

Typical checks that monitoring tools perform include:

• Validating the response code. For example, an HTTP response of 200 (OK) indicates that the application responded without error. The monitoring system might also check for other response codes to give more comprehensive results.

• Check integration provider healthy state: like SMS gateways, payment gateways, Governmental gateways, and business related gateways.

• Checking the content of the response to detect errors, even when the status code is 200 (OK). By checking the content, you can detect errors that affect only a section of the returned web page or service response. For example, you might check the title of a page or look for a specific phrase that indicates that the app returned the correct page.

• Access to database and its performance

• Checking resources or services that are located outside the application. An example is a content delivery network that the application uses to deliver content from global caches.

• Checking for the expiration of TLS certificates.

• Measuring the response time 

• Validating the URL that a DNS lookup returns.

23.Event Sourcing

We have a core issue since We moved to database per each service, Who makes the change?!!!

Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. 

Use an append-only store to record the full series of events that describe actions taken on data in a domain, rather than storing just the current state, so that the store can be used to materialize the domain objects. This pattern can simplify tasks in complex domains by avoiding the requirement to synchronize the data model and the business domain; improve performance, scalability, and responsiveness; provide consistency for transactional data; and maintain full audit trails and history that may enable compensating actions.

The CRUD approach has some limitations:

• CRUD systems perform update operations directly against a data store, which can slow down performance and responsiveness, and limit scalability, due to the processing overhead it requires.

• In a collaborative domain with many concurrent users, data update conflicts are more likely because the update operations take place on a single item of data.

• Unless there's an additional auditing mechanism that records the details of each operation in a separate log, history is lost.

The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. Application code sends a series of events that imperatively describe each action that has occurred on the data to the event store, where they're persisted. Each event represents a set of changes to the data (such as AddedItemToOrder).

Benefits

So, You can use the events, to materialize the views, without updating the data, and with the final process, you can update your data models.

 Also improve the performance, and consistency, and enable replaying the events again.

Solution

A good solution to this problem is to use event sourcing. Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic. The application reconstructs an entity’s current state by replaying the events.

 Applications persist events in an event store, a database of events. The store has an API for adding and retrieving an entity’s events. The event store also behaves like a message broker. It provides an API that enables services to subscribe to events. When a service saves an event in the event store, it is delivered to all interested subscribers.

Finally:

Event Sourcing focuses on data persistence and providing a complete, auditable history of changes by storing events 

28. Service Discovery pattern

Service Discovery pattern, is one of the most well-known largescale patterns, as in large scale solution, you have the following issues:

1. How can you deploy multiple nodes of the components to support huge requests from the end-user

2. How can You dynamically distribute the load across the mentioned nodes

3. How can you keep the highest performance for the solution

In order to achieve that in large scale solution, We have the following approaches:

1. Dedicated nodes, which is costly and cant not maintainable

2. Dynamic nodes, which is scalable, and enable the growth of the solution

So, in this model, We have to have the following:

1. Service Client: Which request the service to perform operation

2. Load Balancer: Which take the responsibility for routing the incoming traffic for each service, and you have one single point of communication, and take care, to which instance it should direct the request

3. Service registry: Within large scale solution, Load balancer should know the new IPs that come to the context, Service registry take place, and keep the actual details, like real address, to direct the call for it, with facility to cache the existing instances for the future use.

4. When service comes up, it register itself in the service registry

5. Scaling: Each scaling, new IPs comes to the service registry, store the mapping between services and its corresponding instances.

6. New Deployment: With new deployment, all instances released, and new one come to the service registry

Tools:

The most commonly used tools is:

• ZooKeeper

• Netflex Eureka

• ETCD kubernetes

Benefits of the pattern:

1. Application of leader election design pattern: Which takes the most active and reliable service in the first fail of the service, Since it's stateless transaction, so each call is totally independent than the other one, so the same instance can serve multiple clients.

2. Higher availability, during the leader election, and  service registry

3. Simplicity of architecture, which prevent thinking about the physical nodes, and growth

4. Scalability of the solution, which meets the largescale solutions

32.Throttling ( and Rate limiting)

Throttler: In the simplest form of API throttling, the throttler would be part of the API server, and it would monitor the number of API requests per second and minute, per user, or per IP address based on user authentication. 

Rate limitter : is the practice of limiting the number of requests that can be made to an API within a specific time period. 

Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service. This pattern can allow the system to continue to function and meet service level agreements, even when an increase in demand places an extreme load on resources.

As a guide, do not provide information without request or exceeding the customer/user needs.

Processing consumes the traffic and become expensive than on prime model.

There're many strategies available for handling varying load in the cloud, depending on the business goals for the application. One strategy is to use auto-scaling to match the provisioned resources to the user needs at any given time. This has the potential to consistently meet user demand, while optimizing running costs. However, while auto-scaling can trigger the provisioning of additional resources, this provisioning isn't immediate. If demand grows quickly, there can be a window of time where there's a resource deficit.

An alternative strategy to auto-scaling is to allow applications to use resources only up to a limit, and then throttle them when this limit is reached. The system should monitor how it's using resources so that, when usage exceeds the threshold, it can throttle requests from one or more users.  

This pattern should be used for governance, and known by infrastructure team, as it affects the operational cost, which is shared between the teams.

So, the advantages of this pattern is It controlling the cost, and enable preventing DDoS.

If your solution does not require throttling, do not enable it.

Why Do Businesses Implement Rate Limiting?

• Preventing overloading of servers: Helps prevent overloading of servers by controlling the rate at which requests are received. By restricting the number of requests made within a certain time frame, you can maintain the stability and responsiveness of your servers.

• Protecting against malicious attacks: Protects against malicious attacks, such as denial of service (DoS) attacks, which are intended to flood servers with excessive requests. By limiting the rate at which requests can be made, you can prevent these types of attacks from causing damage.

• Managing resources and costs: Manages resources and costs by controlling the usage of APIs. By limiting the number of requests that can be made, you can use your resources in the most efficient way and avoid incurring unnecessary costs associated with excessive API usage.

32. Sidecar pattern

Plan for extending your functionality beside your core one.

Deploy components of an application into a separate process or container to provide isolation and encapsulation. This pattern can also enable applications to be composed of heterogeneous components and technologies.

This pattern is named Sidecar because it resembles a sidecar attached to a motorcycle. In the pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent.

Example:

Infrastructure API. The infrastructure development team creates a service that's deployed alongside each application, instead of a language-specific client library to access the infrastructure. The service is loaded as a sidecar and provides a common layer for infrastructure services, including logging, environment data, configuration store, discovery, health checks, and watchdog services.

Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. These peripheral tasks can be implemented as separate components or services.

If they are tightly integrated into the application, they can run in the same process as the application, making efficient use of shared resources. However, this also means they are not well isolated, and an outage in one of these components can affect other components or the entire application. Also, they usually need to be implemented using the same language as the parent application. As a result, the component and the application have close interdependence on each other.

A sidecar service is not necessarily part of the application, but is connected to it. It goes wherever the parent application goes. Sidecars are supporting processes or services that are deployed with the primary application.  

The sidecar pattern is often used with containers and referred to as a sidecar container or sidekick container.