34. Distributed systems
Answer as submitted
“Yes — distributed systems are the core of my architecture experience, across enterprise middleware, microservices and cloud-native platforms.”
Expanded answer
Yes, across enterprise middleware and cloud-native platforms. The division follows bounded contexts rather than layering: services own their data, no database is shared, and the event-driven backbone between contexts replaces the synchronous chain that would otherwise couple their availability. Synchronous calls are used only where the caller genuinely needs the answer now, and every one carries a deadline and a retry budget, because a slow dependency without a deadline becomes thread-pool exhaustion in the caller. Asynchronous messaging carries the rest: a schema, a version and an ordering key, partitioned by aggregate id so ordering is per entity rather than global, with the consumer acknowledging only after the side effect is committed. Reliability is a pipeline rather than a collection of tricks — timeout, bulkhead, retry with jitter, circuit breaker, dead-letter queue — whose order is the design, wrapped around consumers that are idempotent by construction because at-least-once is a property of the transport and cannot be negotiated away. Operability is what makes it real: stateless services, scale signals that predict load rather than merely exist (queue depth for consumers, not CPU), rollouts that drain in-flight work, and one correlation id following a request across every hop. The failures I plan for are the unglamorous ones: messages arriving twice, arriving out of order, a consumer killed mid-message, and a dependency that is slow rather than down.
| Concern | Decision | What it prevents |
|---|---|---|
| Division | bounded context per service, its own data, events between contexts | the distributed monolith: services that must be deployed together |
| Synchronous calls | a deadline and a small retry budget on every outbound call | thread-pool exhaustion in the caller when a dependency slows down |
| Asynchronous messaging | schema plus version plus ordering key, partitioned by aggregate id | assuming global ordering, which is a guarantee no broker gives |
| Delivery semantics | assume at-least-once, dedup by message id in the same transaction as the effect | duplicate side effects after a redelivery |
| Failure handling | timeout, bulkhead, jittered retry, breaker, DLQ in that order | retry storms after an outage and one poison message blocking a partition |
| Operability | stateless services, load-predicting scale signals, graceful shutdown, one correlation id | backlogs nobody can see and requests lost during a rollout |
Live distributed-systems workflow proof
The running component below changes its concern/result view through real event binding. Select a concern to see the design, the reasoning behind it, and the evidence that it holds.
Choose a concern of the distributed design
Select a concern to inspect the design, the reasoning and the evidence.
$ three bounded contexts as services · event-driven backbone between them · Oracle SOA on-premises ↔ AWS in the cloud
Microservices where a bounded context and its owning team justify the split, an event-driven backbone between contexts instead of synchronous chains, and an explicit hybrid path where on-premises middleware has to coexist with cloud services. The style follows the boundary rather than the fashion.
services owning exactly one bounded context: 3 shared database between services: 0 on-prem ↔ cloud integration paths: 2 (message bridge, API gateway)
What the distributed design buys
Source files
Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the others are the resilience pipeline with its idempotent consumer, the event contract the consumers see, and the running topology with its scale signals and observability.
Acceptance criteria
- Divides the system by bounded context and keeps data ownership per service.
- Bounds every synchronous call with a deadline and a small retry budget.
- Shows an interactive proof of choosing a concern and reading the evidence.
- States the delivery and ordering guarantees, and makes consumers idempotent and version-aware.
- Describes how the system is scaled and observed, not only how it is written.