Microservices General discussion

Initial info stolen from https://levelup.gitconnected.com/12-microservices-pattern-i-wish-i-knew-before-the-system-design-interview-5c35919f16a2

API Gateway Pattern: Your One-Stop-Shop for Microservices

Are you tired of managing multiple entry points for your microservices? The API Gateway pattern is here to save the day! Acting as a single entry point for all client requests, the API Gateway simplifies access to your microservices, offering seamless communication between clients and services.

Why should you care about the API Gateway? First, it helps in aggregating responses from multiple microservices, reducing the number of round trips between clients and services. This results in improved performance and user experience. Second, it enables you to implement cross-cutting concerns such as authentication, logging, and rate limiting at a single place, promoting consistency and reducing redundancy.

Imagine the convenience of having a central hub that takes care of all these responsibilities! According to a study by RapidAPI, 68% of developers who adopted API Gateway reported improved security and simplified management of their microservices.

Service Discovery Pattern:

Take a look at Grokking Microservices Design Patterns to master these microservices design patterns for designing scalable, resilient, and more manageable systems.

Service Discovery can be achieved through two main approaches: client-side discovery and server-side discovery. Client-side discovery involves the client querying a service registry to find the target service’s location, while server-side discovery relies on a load balancer to route requests to the appropriate service. Tools like Netflix Eureka, Consul, and Kubernetes offer built-in Service Discovery solutions to cater to your specific needs.

Circuit Breaker Pattern: Shield Your Microservices from Cascading Failures

Are you concerned about the ripple effect of failures in your microservices architecture?

Circuit Breakers can be easily implemented using libraries like Netflix Hystrix and Resilience4j. These libraries offer a range of features, such as fallback methods and monitoring, to help you manage and recover from failures efficiently.

Bulkhead Pattern

Another part of minimizing the impact of failures
Designing and implementing Bulkheads involves creating dedicated resources for each service, such as separate thread pools or database connections.

CQRS Pattern

The CQRS (Command Query Responsibility Segregation) pattern is the answer! This pattern separates the read and write operations of your services, allowing you to fine-tune each aspect independently for maximum efficiency.
CQRS involves segregating your services into two distinct parts: one for handling commands (write operations) and another for handling queries (read operations). This separation allows you to apply different scaling, caching, and database strategies for each operation type. Popular frameworks, such as Axon and MediatR, offer built-in support for implementing the CQRS pattern.

## Event-Driven Architecture Pattern

This pattern leverages events to trigger actions in your services, enabling real-time responsiveness and promoting loose coupling between services.
Popular tools, such as Apache Kafka, RabbitMQ, and Amazon Kinesis, enable you to implement this pattern effectively in your microservices architecture.

Saga Pattern

The Saga pattern offers a reliable solution for handling distributed transactions, ensuring data consistency while maintaining the autonomy of your services. In a microservices architecture, transactions often span across multiple services, making traditional ACID (atomicity, consistency, isolation, and durability) transactions unsuitable. breaking down a distributed transaction into a series of local transactions, each followed by an event or a message. If a local transaction fails, compensating transactions are executed to undo the completed steps, maintaining data consistency. Tools like Eventuate and Axon provide built-in support for implementing the Saga pattern in your microservices architecture.

Retry Pattern

This pattern involves automatically retrying a failed operation, increasing the chances of successful execution and minimizing the impact of temporary issues.

Why should you adopt the Retry pattern? In a microservices ecosystem, transient failures such as network hiccups or service timeouts are inevitable. The Retry pattern enables your services to recover gracefully from these issues, enhancing overall system stability.
The key to successful implementation lies in defining a suitable retry strategy. This strategy should include factors like the maximum number of retries, delay between retries, and any exponential backoff. Libraries like Polly, Resilience4j, and Spring Retry offer built-in support for implementing the Retry pattern in your microservices.

Backends for Frontends Pattern (BFF)

This sounts initially like just more duplication?
Why should you consider the BFF pattern? In a microservices architecture, a single backend service might not cater to the diverse requirements of different frontends. The BFF pattern enables you to customize your backend services for each platform.

Sidecar Pattern

Do you want to extend your microservices’ functionality without compromising their autonomy? The Sidecar pattern enables you to add new features or cross-cutting concerns without affecting the main service, preserving modularity and maintainability.
Examples of Sidecar implementation include the Envoy proxy in a service mesh and the Fluentd logging sidecar.

Strangler Pattern: Transform Your Monolith into Microservices with Confidence

This pattern enables you to gradually replace your monolithic system with microservices, ensuring a smooth and risk-free transition. To implement the Strangler pattern, you start by identifying a specific functionality within your monolithic system. You then create a new microservice to handle that functionality and redirect requests to the new service using an API gateway or proxy.

etcd

A distributed, reliable key-value store for the most critical data of a distributed system etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node. https://etcd.io/