Without reading any code, what deployment and operational signals would tell you a 'microservices' system is actually a distributed monolith?

## Why runtime data beats reading code Detecting a distributed monolith from operational data alone is a legitimate and often faster method than reading code, because code review requires access and expertise across every service and can be misleading: source can look decoupled, with separate repos and separate services, while runtime behavior proves otherwise. Deployment and observability data, centrally available from the CI/CD system, tracing backend, and incident tooling, reflects what the system actually does under real conditions rather than what its structure merely suggests. ## Deploy correlation The first concrete signal is **deploy correlation**. - Pull deploy timestamps per service from the CI/CD system over a meaningful window, such as ninety days, and compute how often one service's deploy falls within a short window, say plus or minus one hour, of another service's deploy. - A high correlation across many separate deploys, not just one shared release, indicates a forced dependency rather than coincidence. - Also look for explicit **release-train calendars** or change-freeze processes that name multiple services together — an organizational artifact that mirrors technical lockstep. ## Incident and postmortem language The second signal is incident and postmortem language. Search postmortems for recurring phrases like 'root cause in Service X caused errors in Service Y or Z.' A distributed monolith shows this pattern chronically, across many unrelated incidents over time, not just once as an unlucky coincidence. It's also worth pulling uptime and error-rate dashboards to check whether a service's historical downtime correlates with SLO breaches in nominally unrelated services during the same windows. ## Trace waterfalls The third signal comes from **distributed tracing**. Trace waterfalls reveal whether an incoming request fans out into a long synchronous chain with no fallback or circuit-breaker spans, versus a shallow call graph with async hops. A distributed monolith's traces typically show deep, wide synchronous fan-outs where a slow leaf span visibly inflates the root span's total duration — **temporal coupling** made visible directly in the trace. ## The organizational echo The fourth signal is organizational, an echo of **Conway's Law** used in reverse to diagnose rather than predict coupling. - Check code-review approver overlap and on-call rotation overlap across services that are nominally separate: if the same handful of engineers approve pull requests and get paged for both Service A and Service B, that's a proxy for coupling even before checking deploy timestamps, because tightly coupled services tend to require the same people's context to change safely. - Combine this with **database access logs** where available, checking which services' credentials query which tables — a service whose credentials touch tables 'owned' by three other services is a strong, concrete signal. ## A worked scenario A worked scenario ties these together. An SRE investigating a persistent Friday deploy-freeze spanning twelve nominally independent services: 1. pulls CI deploy history and finds nine of them deploy within the same two-hour window on every release; 2. cross-references postmortems and finds six incidents in the last quarter where one service's database migration caused timeouts in two unrelated services; 3. and finds via tracing that the checkout service's p99 latency is dominated by a synchronous call four hops deep into a legacy inventory service with no timeout configured. That combination of deploy correlation, cascading-incident history, and a trace waterfall is enough to diagnose a distributed monolith without reading a single line of application code, and it also gives concrete, prioritized remediation targets: the inventory call chain first, since it's both the largest latency and the largest incident contributor.