Part 17 of 17 · ~2 min
Common Mistakes Worth Remembering
- Starting a new product as microservices "for scale" before there's any actual load or team-size problem to justify it — paying the full operational and consistency cost with none of the organizational benefit yet.
- Sharing one database across "microservices" — that's just a monolith with extra network calls and none of the actual independent-deployment or independent-scaling benefits, since a schema change still needs cross-service coordination.
- Making a cross-service call synchronous by default without a timeout, retry policy, or circuit breaker — turning one slow dependency into a cascading outage across everything that calls it.
- Treating a Saga's eventual consistency as if it were the same guarantee as an ACID transaction — designing a step that can't actually be compensated if a later step fails.
- No distributed tracing or correlation IDs — when a request fails somewhere across five services, "somewhere across five services" isn't good enough to debug.
- Assuming a service boundary drawn once is permanent — the right boundaries usually only become clear after living with the system for a while; the strangler fig pattern exists precisely so those boundaries can be revised incrementally.
- Attempting a full microservices rewrite in one shot instead of an incremental, strangler-fig-style extraction that keeps the system shippable throughout.
- Splitting services along technical layers (a "database service," a "UI service") instead of business capability (Orders, Payments, Inventory) — the former still requires nearly every change to touch multiple services, which recreates monolith-style coupling with microservices-style overhead.
The ACID, SOLID & Design Patterns article covers the Saga pattern and other cross-cutting design ideas — like the resilience patterns above — that come up constantly once you're operating more than one service. See Docker Fundamentals and CI/CD Pipelines Explained for how the individual services this reference describes actually get packaged, tested, and deployed in practice. Practice designing and reasoning through systems like these in the code lab.