Microservices Cheatsheet

Service Decomposition Heuristics

Map a real-world signal to a decomposition decision. If two signals point opposite ways, the louder one usually wins.

Communication Patterns

Pick the pattern by the answer the caller needs and how soon it needs it.

Quick rule

• If the caller needs an answer to continue → sync.
• If the caller is announcing a fact → async event.
• If the caller is requesting work → async queue with idempotency key.

Resilience Patterns Cheatsheet

Compose them in order: bulkhead → circuit breaker → timeout → retry → fallback. See Circuit Breaker & Resilience for full implementations.

Data Patterns

The hard problem in microservices is data. Pick the lightest pattern that solves your case.

API Versioning Quick Reference

Pick one strategy and apply it everywhere — mixing versioning styles within an org is the real failure mode.

Rules of thumb

• Additive changes (new optional field) → no version bump.
• Removing or renaming a field → new version + deprecation window (6–12 months).
• Document Sunset/Deprecation headers; honor them in clients.

Deployment Strategies Quick Reference

Observability Pillars

Three signals; each answers a different question. You need all three.

Golden signals to alert on (Google SRE)

• Latency — P50, P95, P99 of successful requests.
• Traffic — requests per second by route.
• Errors — rate of 5xx and explicit failures.
• Saturation — how close to capacity (CPU, memory, queue depth, pool usage).

Security Quick Reference

Three rules

• Rotate everything: keys, certs, tokens, passwords. Automate it.
• Default deny at the network and the policy layer. Allow narrowly.
• The build pipeline is part of the attack surface — sign artifacts and verify on deploy.

Common Anti-Patterns

If you recognize one of these in your stack, fix it before adding more services.

• Distributed monolith — many services that must deploy together. You got the network calls without the independence.
• Shared database — multiple services hitting the same schema. Schema changes cascade; ownership is undefined.
• Chatty services — one user action triggers 30 internal hops. Latency dies of a thousand cuts.
• Synchronous chains — A calls B calls C calls D, all blocking. Availability is the product of all four.
• No idempotency — retries cause double-charges, double-shipments, double-emails.
• Hand-rolled service discovery — YAML lists of hosts. Use DNS, the platform, or a mesh.
• Hand-rolled retries — ad-hoc loops with no jitter, no budget, no breaker. Causes retry storms.
• God service / data hub — one service that knows everything; everyone depends on it.
• Nano-services — a service per function. More glue than logic; ops cost dwarfs feature work.
• Versionless events — producers change payloads silently; consumers break.
• Cross-service transactions — trying to make a saga look like one ACID transaction. Embrace the asynchrony.
• Logs without correlation IDs — you cannot debug a distributed request from one service’s logs alone.
• Snowflake environments — staging differs from prod “just a little.” That little is where outages live.
• Manual deploys — humans clicking through pipelines. Automate or accept the outages.
• One repo, no boundaries — monorepo with no module ownership; every change touches every service.

Tooling Cheatsheet

Pick one per category and standardize. Two tools competing for the same job is the most expensive choice.

When NOT to Use Microservices

Microservices are an answer to a problem of scale — team scale, traffic scale, change scale. Without that problem, they are pure cost.

• Small team (<10 engineers). You don’t have enough people to staff the platform work. Stay monolithic.
• Greenfield product, unclear domain. You don’t know your bounded contexts yet. Splitting too early calcifies the wrong seams.
• No production observability. Microservices without tracing and centralized logs is debugging blindfolded.
• No CI/CD. If deploys are manual, multiplying services multiplies pain.
• Strong cross-entity transactional needs. If everything must be ACID across N entities, the database wants to keep them together.
• Latency-critical inner loop. Sub-5 ms paths can’t afford a network hop per call.
• Predictable, low-traffic workload. One box runs your monolith forever and that’s fine.
• No platform team / no plan to build one. Without paved roads, every service team reinvents the wheel.
• Org cannot tolerate eventual consistency. Some businesses really do need “the answer is correct right now” everywhere.
• You’re trying to fix a code-quality problem. A bad monolith becomes a bad distributed monolith. Refactor first.

Start here instead

• Modular monolith with clear internal module boundaries.
• One database, multiple schemas owned by different modules.
• Extract the first service only when a real signal (team split, scaling, compliance) forces it.