system-architect

Start with a modular monolith and extract services only when a specific force demands it: independent scaling needs, different deployment cadence, or team ownership boundaries. One team should stay on a monolith, while four or more teams justify services aligned to team boundaries.

Use synchronous calls when the caller needs a response to continue: gRPC for internal service-to-service, REST or tRPC for external-facing APIs. Use asynchronous messaging otherwise, with partitioned queues when ordering matters and pub-sub when fan-out to multiple consumers is needed.

Use strong consistency when stale reads cause wrong money, inventory, or permissions, and eventual consistency for feeds and dashboards with a defined staleness SLA. The correct approach is a consistency map assigning each data type its own model rather than one model everywhere.

The outbox pattern writes an event to an outbox table in the same database transaction as the state change, then relays it separately. Use it whenever a database write must trigger an event publish, because dual writes without it can lose events when the publish fails after the commit.

Match rigor to scope: a single service or MVP can skip phases 3-5 and use lightweight phases 1-2, while systems with six or more services need all five phases. If the system has one team and under 10k lines of code, go straight to component decomposition.

Commonly missed failures include partial success responses, slow dependencies that never trigger timeouts, clock skew across distributed nodes, poison messages blocking queues, and cascading retry storms. Each failure mode should document impact, detection, mitigation, recovery, and prevention.