The distributed-monolith anti-pattern, shared databases breaking service isolation, chatty synchronous chains, and four real production incident scenarios walked through diagnostically.
Published September 23, 2026
Every pattern earlier in this chapter (circuit breakers, bulkheads, retries) exists because microservices architectures fail in specific, recurring ways. This lesson names those failure modes directly.
Services that are technically separate deployables but can't actually be deployed independently — a change to Service A requires coordinated, simultaneous deployment of Service B and C because they share tightly-coupled contracts, database schemas, or synchronous dependencies with no tolerance for version skew. This delivers all of microservices' operational cost (more services to monitor, deploy, and keep available) with none of its actual benefit (independent deployability) — see Monolith to Microservices Decomposition's bounded-context reasoning for how proper decomposition avoids this trap in the first place.
The single most common way teams accidentally build a distributed monolith: multiple services reading/writing the same database tables directly. This breaks the core isolation promise (see Data Ownership Model) — a schema change in one "service's" tables can silently break another service that also queries them, and there's no way to reason about one service's behavior in isolation when its actual data dependencies are invisible, hidden inside shared tables rather than explicit APIs.
Gateway → Service A → Service B → Service C → Service D
(each hop synchronous, each adding its own latency AND its own failure probability)
Every additional synchronous hop multiplies both latency (each hop's latency adds to the total) and failure surface (the overall request now fails if ANY of the four services has a problem, not just one) — a chain of four 99.9%-available services synchronously calling each other has a combined availability closer to 99.6%, not 99.9%, since the whole chain fails if any link does. This is a direct, concrete argument for Inter-Service Communication Choices' hybrid sync/async guidance — minimizing unnecessary synchronous depth, not eliminating synchronous calls entirely.
Without centralized logging, distributed tracing, and metrics (this course's next three lessons), a failure in a multi-service chain is nearly impossible to localize quickly — "the checkout is slow" could mean any of ten services, and without correlation IDs tracing a single request across all of them, diagnosing which one is actually the bottleneck becomes guesswork under incident pressure. Observability isn't a nice-to-have layered on top of microservices — past a certain service count, it's the only practical way to operate the system at all.
Splitting into services before domain boundaries are actually well understood tends to produce boundaries that don't match real business capabilities — the resulting services need constant cross-boundary communication and coordination (functionally a distributed monolith again), because the split was drawn along a guess rather than a validated bounded context. A monolith with well-factored internal modules is a better starting point for eventual decomposition than a premature split along the wrong lines (see Monolith to Microservices Decomposition's "find the seams" guidance).
Every service needs its own monitoring, deployment pipeline, and on-call coverage — a team splitting into 15 microservices without a proportional increase in operational tooling/automation is signing up for 15x the operational surface area with the same headcount, a cost that's easy to underestimate when focused purely on the architectural benefits of decomposition.
First checks, in rough priority order: a missing index from a new query introduced in the deployment (see Query Execution Plans — check EXPLAIN output first), a connection pool misconfiguration (a new deployment that changed pool size settings, or added a new query path that exhausts the existing pool faster), or a synchronous call to a newly-introduced slow dependency (a new feature that added a chatty synchronous hop). The "right after a deployment" timing is the strongest diagnostic clue — check what actually changed in that deployment first, before broader investigation.
This specific combination — high thread count, low CPU — indicates threads are blocked waiting, not actively computing: waiting on I/O, a lock, or a starved connection pool, not CPU-bound work. A thread dump (jstack) confirms this directly, showing exactly what each blocked thread is waiting on — this is a fundamentally different diagnosis path than high-CPU-high-thread-count (which would point toward inefficient computation, not blocking), and conflating the two wastes investigation time.
Common causes: multiple application instances each running their own independent scheduler without a distributed lock (see Design: Distributed Task Scheduler's double-execution problem) — every instance thinks it's the only one and each runs the job on schedule — or a misconfigured cron trigger overlapping with a still-running previous execution (the job takes longer than the schedule interval, so a new instance starts before the last one finished). Both point to the same missing safeguard: coordination (a distributed lock, or an overlap-prevention check) that a single-instance deployment never needed but a multi-instance one requires.
The health check is almost always too shallow — checking only that the process is alive and responding to /health, not that it can actually serve real requests or reach its own dependencies. A process can be technically "up" while its database connection pool is exhausted, or its critical downstream dependency is unreachable — this is exactly the liveness vs readiness distinction Health Checks covers, and the fix is a readiness check that actually exercises the dependency paths real traffic needs, not just confirming the process itself hasn't crashed.
Q: How would you distinguish a distributed monolith from a genuinely well-decomposed microservices architecture, from the outside? A: The tell is deployment coupling — if deploying Service A reliably requires simultaneously deploying Service B (even informally, as a 'always deploy these together' team convention), that's a distributed monolith regardless of how the code is physically split across repos/deployables.
Q: Why does the 'chatty synchronous chain' availability math work out worse than naive intuition might suggest? A: Combined availability of independent components in series multiplies, not averages — four services each at 99.9% combine to roughly 0.999^4 ≈ 99.6%, and this compounds further with each additional synchronous hop, which is why minimizing unnecessary synchronous depth has an outsized effect on overall system availability.
Q: Is 'shared database' ever acceptable between two services? A: Generally treated as an anti-pattern to avoid, but a narrow, deliberate exception sometimes exists for a genuinely shared, rarely-changing reference dataset (not transactional data) accessed read-only by multiple services — even then, most teams prefer an explicit API or event-driven replication over direct shared-table access, to avoid the schema-coupling risk even for read-only cases.
Q: What's the single most cost-effective fix among everything in this lesson for a team just starting to operate microservices? A: Observability (centralized logging + correlation IDs, at minimum) tends to have the highest leverage-per-effort — every other failure mode in this lesson becomes dramatically faster to diagnose once you can trace a single request's actual path and timing across services, even before adding circuit breakers, bulkheads, or other resilience patterns.