Distribution & Distributed Basics

A track of P38 · Architecture, Services & Distribution.

Design for the network: know when a monolith should become microservices, and build the primitives that make remote calls survivable - retry with backoff and idempotency, so partial failure is recoverable and a retry runs the effect once.

The last track zooms out to where services live: distributed systems. It's two questions — when to distribute at all, and how to make remote calls survivable — and you build the primitives by hand rather than trusting a framework.

The judgement half: a well-structured monolith is simpler to build, test and run (one database, one transaction, no network), and you split into services only on a real force — independent scaling, team autonomy, fault isolation — along a clean domain seam, not "one service per noun". The build half: once a call crosses a network you get partial failure (the effect may have happened but the reply was lost), so you write retry with backoff (try again, waiting longer each time, with a timeout) and idempotency (key the effect so a repeat runs once). Together they are the backbone of reliability — and exactly why a queue can promise at-least-once delivery: the consumer is idempotent. You build both on a logical clock, so the backoff schedule is deterministic and testable; real queues and network stay prose.

monolith firstsplit only on a real forcepartial failurethe reply may be lost, not the effectretry + backoffrecover transient failures, politelyidempotencya repeat runs once - retries are safe
Distribute on purpose; design every remote call to be recoverable.