Distributed Systems Patterns

If the system isn't distributed yet: gate first

Most systems should stay a modular monolith (clear internal boundaries via warisskill-system-design-domain-modeling, but one deployable) until a concrete trigger forces distribution. Reach for a distributed pattern only when one of these is actually true, not speculatively:

• A specific component needs independent scaling — e.g. heavy background processing that shouldn't compete for resources or deploy cadence with the main app.
• A team boundary requires independent deployability — different owners need to ship on separate schedules without coordinating releases.
• A genuine cross-boundary async workflow exists — a multi-step process spanning ownership/data boundaries that can't be one transaction (e.g. payment → inventory → notification).