Distributed Services
Large systems are many services talking over a network. That brings questions a single program never had: how do services talk, what if a message arrives twice, how do you keep data consistent across services, and who is in charge when nodes disagree?
- C5.1Monolith, modular monolith, microservicesMonolith One deployable app, one database. Simple to build, test, deploy and debug. In-process calls are fast and transactional. Hurts when…
- C5.2Synchronous calls vs eventsSynchronous (REST/gRPC): the caller waits for an answer. Simple, but it couples availability: if any service in the chain is down or slow,…
- C5.3Transactions across services: 2PC and sagasPlacing an order touches payments, inventory and shipping, each with its own database. There's no single transaction. Two-phase commit…
- C5.4Delivery guarantees and idempotent consumersAt-most-once: send and forget. Messages can be lost, never duplicated. At-least-once: retry until acknowledged. Nothing is lost, but…
- C5.5Leader election and consensusMany systems need one node in charge: the database leader, the lock holder, the scheduler that must run a job once. If the leader dies, the…