You're Already Using Distributed Systems (You Just Don't Know It) - Part 1

Introduction

In my experience as a developer, I've met plenty of people who think distributed systems are magical. They're not - they add complexity, certainly, but once you understand them, the pitfalls become obvious.

This is my attempt at simplifying the concept. It's how I'd explain it to my mother, who isn't technical at all. But first, let me say this: unless your application runs on a single machine without any network access (not even localhost), you're already using and/or part of a distributed system.

You probably recognise these concepts already:

• Eventual consistency
• Communication costs
• Load balancing
• Service discovery

The Street Food Vendor: Your Monolith

Every culture has street food vendors, so this should be relatable. The street food vendor is your monolith application. One person does everything: takes orders, cooks food, handles payment, serves customers. In the evening, the same person does the accounts and buys tomorrow's supplies.

There's no delay between taking an order and starting to cook it. Ask about your order's status, and they know immediately. This model works brilliantly when you're starting out, figuring out what sells and what doesn't.

But when business grows and you hire help, complexity creeps in.

When Two Becomes a Crowd

With two people, you face your first architectural decision: how do you split the workload?

Option 1: Multiple food trucks - expensive but simple. Each person handles everything independently. Think of this as horizontal scaling with complete isolation.

Option 2: Shared workspace - cheaper but introduces communication challenges. This is where distributed systems principles really kick in.

Load Balancing in Action

In Option 2, you can split the load two ways:

1. Shared responsibilities: Both staff handle the same tasks. Work gets distributed evenly, or whoever finishes first serves the next customer. This is load balancing in its purest form.

2. Specialised roles: One person takes orders, another cooks. This introduces the concept of domain boundaries - something we'll explore more in Part 2.

The Trade-offs Begin

Shared responsibilities keep things simple. One person handles an entire order from start to finish, maintaining what we call strong consistency. They always know exactly where each order stands. It's either all done or not done at all.

However, scaling becomes harder. You need staff with every skill: customer service, food preparation, cooking, cleaning. Finding such people gets increasingly difficult and serving more customers (scaling) gets harder.

Specialised roles offer efficiency gains. If two customers order the same dish, they can be prepared simultaneously rather than sequentially. But this introduces complexity we'll dive into next time.

What's Coming Next

In Part 2, we'll explore what happens when you specialise roles. We'll cover:

• Domain boundaries and microservices
• Communication protocols between services
• Why eventual consistency becomes inevitable
• The famous CAP theorem (and why it matters)

We'll see how restaurants solve these problems and how the same solutions apply to software systems.