arch-reviewlisted

# Arch Review Distributed systems fail in ways that single-process systems don't. The goal of an architecture review is to find the failure modes, consistency problems, and operational gaps before they find you in production. ## How to run a review Work through these areas in order — earlier sections surface problems that change how you think about later ones. --- ## 1. Service boundaries and data ownership **Each service should own its data.** If two services share a database, they're not two services — they're one service split across two codebases. Shared databases create hidden coupling: schema changes in one service break the other; transactions span service boundaries and become distributed transactions (hard) or are abandoned (inconsistent). **Ask for each service:** - What data does it own? (Only it can write directly to this data) - What does it depend on from other services? (Read-only copies, published events, or synchronous queries) - What does it publish to other services? **Red flags:** - Two services writing to the same table - A service querying another service's database directly - Business logic that's split between two services and requires tight coordination to remain consistent **Bounded context drift**: if a service has grown to own data and logic from multiple unrelated domains, it's becoming a distributed monolith. Consider whether it should be split. --- ## 2. Communication patterns **Synchronous (request/response)**: service A calls ser