The Course at a Glance

Microservices design patterns are standard solutions to problems that appear when software is built as a set of small, independently deployable services. Each one names a problem, describes a solution, and comes with a cost.

This course covers sixteen of them.

1. Strangler Fig Pattern: Replaces an old system with new services one piece at a time. There is no single day when everything switches over.

2. API Gateway Pattern: Puts one entry point in front of the services, so a client calls one address instead of many.

3. Backends for Frontends (BFF): Gives each kind of client its own backend, so a phone and a desktop are not served the same response.

4. Service Discovery Pattern: Lets services find each other's current addresses, instead of using a fixed list that is soon out of date.

5. Circuit Breaker Pattern: Stops calling a failing dependency for a while, so one broken service does not make its callers fail too.

6. Bulkhead Pattern: Keeps a separate set of resources, such as threads, for each dependency. Then one busy dependency cannot use up what the rest of the service needs.

7. Retry Pattern: Repeats a call that failed for a temporary reason, with a delay that grows between attempts.

8. Sidecar Pattern: Runs a helper container beside a service, so platform features are added without changing the service code.

9. Service Mesh Pattern: Moves retries, timeouts, encryption and metrics into a proxy beside every service, so that behavior stops being application code.

10. Database per Service Pattern: Gives every service its own private data store, so schemas, scaling and failures stop being shared.

11. Saga Pattern: Keeps data correct across services without one transaction that spans them all. When a later step fails, the earlier steps are undone.

12. Transactional Outbox Pattern: Records an event in the same transaction as the data change, so the change and its event are saved together or not at all.

13. Event-Driven Architecture Pattern: Has services publish events instead of calling each other directly. The service that publishes an event does not need to know who receives it.

14. CQRS Pattern: CQRS stands for Command Query Responsibility Segregation. It separates the model that changes data from the model that reads it, so each one fits its own job.

15. Event Sourcing Pattern: Stores every change as an event that is never edited or deleted. State is computed by replaying those events, so the full history is always available.

16. Configuration Externalization Pattern: Keeps settings outside the build, so a value can change without a new deployment.

How the Chapters Work

The course ends with a final exam that draws on every chapter, so leave time for it.

Each chapter follows the same shape. It states the problem in plain terms, describes the pattern, works through code, and covers what the pattern costs in practice. Every pattern chapter ends with flashcards and an assessment.

The patterns also build on each other. Service discovery appears again in configuration externalization. The circuit breaker and the retry pattern handle the same failure in two different ways. Database per service creates the data separation that the saga, the outbox, CQRS and event sourcing then manage. The service mesh performs the retry and circuit breaker patterns for you, so those two chapters come first. Read them in order the first time.

Let us start with the first pattern.