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.
Splitting the system into services was supposed to make it easier to change. Six months on, a single feature touches four repositories, nobody can run the whole thing locally, and the failure everyone quietly dreads is the one where the payment succeeded and the order service never heard about it. Distribution did not create that risk by accident — it is the price of the network, and it has to be paid deliberately or not incurred at all.
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.