When Simple Becomes Complex: Domain Boundaries and the CAP Theorem
Quick Recap
In Part 1, we established that distributed systems are everywhere. We explored the street food vendor (monolith) and saw how adding a second person introduces architectural decisions: either run multiple independent food trucks (expensive but simple) or share a workspace with specialised roles (cheaper but more complex). Now let’s dive into what happens when you choose specialisation.
Specialised Roles: The Birth of Domain Boundaries
When you split roles – one person taking orders, another cooking – you’ve created domain boundaries. In restaurants, these are often literal walls separating the dining room from the kitchen. In software, these become microservices.
The order-taker specialises in customer service, menu knowledge, and payment processing. The cook specialises in food preparation, timing, and presentation. Each becomes highly efficient within their domain.
The Communication Problem
But here’s where complexity enters. Information must now travel between domains. Your order gets written down (or entered into an iPad) and passed through. This takes time that doesn’t exist when one person handles everything.
In computer systems, this handover is even more critical. You need:
- Reliable delivery: Ensuring the chef receives the order
- Retry mechanisms: Resending if the first attempt fails
- Idempotency: Making sure repeated orders aren’t cooked twice
That order number the chef checks? That’s an idempotency key in action.
Back Pressure and Flow Control
Another issue emerges: the order-taker doesn’t know how busy the kitchen is. They might keep taking orders whilst the chef gets overwhelmed. This is back pressure – when downstream services can’t keep up with upstream demand. As system needs to be put in place to feed back available capacity or increase the capacity of the upstream services and share the load as needed aka load balancing (covered in the first post).
When one person handles everything, this isn’t a problem. They simply can’t take the next order until the current one’s finished. Natural flow control.
Consistency Goes Out the Window
Perhaps most importantly, you lose strong consistency. Place an order with the front-of-house staff, and if asked, the chef might say “what order?” because they haven’t received it yet. Ask the order-taker about your food’s status, and they might say “it’s cooking” when it’s actually ready but not yet passed back.
This is eventual consistency. Eventually, everyone who needs to know will have the same information, but there’s a delay. It might be milliseconds or hours, but “eventually” they align.
Enter the CAP Theorem
This brings us to one of distributed systems’ most important concepts: the CAP Theorem. Proven scientifically, the theorem states you can only have two of these three properties:
- Consistency: All parts of the system have the correct state
- Availability: All requests receive responses
- Partition tolerance: The system handles some parts being unavailable
Most systems choose Availability and Partition tolerance, accepting some inconsistency. Financial systems typically choose Consistency above all else – having the correct account balance matters more than anything.
Restaurant Examples of CAP
Consistency: Every order is perfect, staff always know exactly where orders stand, ingredients are guaranteed available when ordered.
Availability: Open 24 hours, enough staff to handle any volume.
Partition tolerance: Enough employees to cover sickness, multiple locations can operate independently.
Fast food chains choose Availability and Partition tolerance. They’re open long hours with enough staff but occasionally get orders wrong. High-end restaurants choose Consistency – perfect service and food but limited hours and advance booking required.
Why Specialisation Wins
Despite the complexity, specialised roles become inevitable for growth. You simply cannot scale a food truck beyond a certain point without splitting responsibilities. The same applies to software systems.
What’s Next
In Part 3, we’ll explore how this scales further:
- Breaking down domains into even smaller boundaries
- Communication protocols and interfaces
- How restaurants (and software systems) solve coordination problems
- Why you’re part of an even larger distributed system
We’ll see how these patterns repeat at every scale, from individual services to entire supply chains.
