Master Microservice Design Patterns by Breaking Things
Work through 47 patterns for the system and the teams that build it. Test yourself on real scenarios and check your own design for anti-patterns. For everyone who learns, builds, designs or leads microservice systems, from students to engineering leaders.
- 14 hands-on labs Crash services and fail steps halfway, then watch which patterns hold.
- 7 team patterns The people side too: reorganise the teams and watch lead time change.
- Checkout response
- 80 ms
- Errors users see
- 0%
Learn it, break it, test it, apply it
- Learn
Read the pattern
47 patterns in 8 categories, for the system and the teams that build it: what each one is, why it exists, how to apply it, when not to, and how it connects to the others.
Open the catalog → - Break
Run a lab
14 hands-on labs. Crash a service, fail a saga halfway, break a mobile app with an API change or reorganise the teams, then switch on the pattern and compare.
Enter the labs → - Test
Answer scenarios
119 scenario questions. A wrong answer explains why and points you back to the patterns to revisit. Your progress and milestones are saved as you go.
Start practicing → - Apply
Review your design
Describe your own services, data stores, calls and the teams that own them. Rule checks flag technical and ownership anti-patterns in your browser.
Review a design →
From students to engineering leaders
Whatever your title, start where your work is.
Learning the field
Students, bootcamp graduates and engineers new to distributed systems.
Building services
Software, backend, mobile and platform engineers.
Designing systems
Architects, staff and principal engineers, and tech leads.
Leading teams
Team leads, engineering managers and delivery leads.
Shaping the organisation
Anyone who decides how teams are structured, such as CTOs, VPs or heads of engineering, directors, chief architects and founders.
How is the system built?
The technical side: where service boundaries go, how services share data and talk, how web and mobile clients fit in, how the system survives failure, and the platform it runs on.
Where do the boundaries go?
How to split a system into services and migrate toward them without a big-bang rewrite.
4 patternsWho owns the data, and how does it stay consistent?
How services own their data and still deliver business outcomes that span several of them.
8 patternsHow do clients and services talk?
How requests and messages move between clients, gateways and services.
8 patternsHow do web and mobile clients fit in?
How web and mobile apps are split between teams, composed into one experience and kept working as the services behind them change.
5 patternsWhat happens when a dependency fails or slows down?
How to keep serving users when parts of the system are broken, slow or overloaded.
5 patternsHow do we see what the system is doing?
How to understand behaviour that is spread across many processes and machines.
3 patternsHow do we build, ship and run it?
How cross-cutting concerns are built once by a platform and shared, so every service ships and runs the same way.
7 patternsLayers and cross-cutting concerns
Every layer from the screen to the database, who owns it, and how concerns such as identity, tracing and versioning work across all of them.
Read the overview →Who builds and runs it?
The people side: how teams are shaped around business capabilities and the platform, how they work together, and who owns each pattern.
How should teams be shaped and work together?
How teams are shaped around business capabilities, layers and the platform, so each team can deliver without waiting on the others.
7 patternsTeams and ownership
Product teams through every layer, platform teams under them, the four team types and who usually owns each pattern.
Read the overview →Not sure where to start?
Draw the boundaries
Start with Decompose by Subdomain and Database per Service. Everything else depends on these two decisions.
Survive failure
Read Circuit Breaker and Retry with Backoff, then run the Circuit Breaker lab to see how they interact.
Stay consistent
Move on to Saga and Transactional Outbox, where most real projects get stuck. Then break them in the Saga and Outbox labs, and see how read models drift in the CQRS and Event Sourcing lab.
Organise the teams
Read Stream-Aligned Team and Platform Team, then reorganise the same product in the Conway's Law lab and watch lead time change.