DEV Community: Beyond the code

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

Beyond the code — Sun, 17 Aug 2025 17:19:39 +0000

Scaling Up: Microservices, Communication Protocols, and the Bigger Picture

Where We've Been

Part 1 showed how you're already using distributed systems. Part 2 explored what happens when you split a simple system into specialised roles, introducing domain boundaries, eventual consistency, and the CAP theorem. Now let's see how this scales further.

Breaking Down the Boundaries

As restaurants grow, they subdivide roles even further. Instead of one waiter handling everything front-of-house, you might have:

Someone to seat customers and take initial orders
A sommelier to recommend wines
Food runners to deliver meals
Different people handling different sections

Each subdivision creates new boundaries. What was once customer → waiter → chef → waiter → customer becomes a complex chain of handoffs. Each step adds latency and potential failure points.

In software terms, this is the evolution from monolith to microservices to nano-services. "Micro" or "Nano" doesn't relate to the lines of code, it relates to the scope of the job being performed. Whether that job is generalised or highly specialised depends on your scale.

The Kitchen Gets Complex Too

The kitchen also subdivides. Instead of one or two chefs doing everything, you get:

Grill specialists
A sauce chef
Vegetable preparation
Pastry specialist
Plating and presentation

All these must coordinate perfectly. If the vegetables are ready but the meat isn't, the dish fails. If the sauce chef is running behind, everyone waits. Multiple dishes for the same table must finish simultaneously.

This is service orchestration in action. Each service (chef) handles its speciality, but coordination from the head chef becomes critical.

Communication Protocols Matter

Restaurants solved this long ago with strict communication protocols. Orders must be legible and contain essential information like table numbers. Missing information? The kitchen rejects it immediately rather than guessing.

Customers don't walk into the kitchen to order directly - there's an interface (waitstaff) that validates and routes requests appropriately. Waiters don't take food directly from the grill - they wait for the chef's signal that it's ready.

In software, this translates to API contracts and service boundaries. Each microservice owns its database. Other services cannot access that data directly - they must go through the service's API. This ensures data integrity and proper validation.

Failure Handling

Restaurants also demonstrate excellent failure handling. If the grill breaks down, they might temporarily remove grilled items from the menu rather than shutting down entirely. If a waiter calls in sick, others cover their sections.

This is graceful degradation - continuing to operate with reduced functionality rather than complete failure. The system remains available (remember CAP theorem?) even when parts fail.

The Bigger Distributed System

Here's the crucial point I want to leave you with: restaurants themselves are just nodes in a much larger distributed system. They have supply chains for ingredients, laundry services for table linens, cleaning companies, payment processors, reservation systems.

Each external dependency introduces the same challenges we've discussed:

Communication delays
Potential failures
Eventual consistency
Need for fault tolerance

The restaurant must handle supplier delays, maintain backup vendors, and design around external service failures. Sound familiar?

Your Software Systems

Your applications exist in this same reality. That database call? Network communication with potential failure. That payment API? External service dependency. User authentication through OAuth? You're part of someone else's distributed system.

Even a "simple" web application typically involves:

Load balancers
Web servers
Application servers
Databases
Caching layers
External APIs
CDNs for static assets
DNS resolution

Each introduces the distributed systems concepts we've covered.

Patterns Everywhere

The beautiful thing is these patterns repeat everywhere. Whether it's restaurant operations, football teams, military units, or software architecture, the same principles apply:

Specialisation improves efficiency but increases coordination complexity
Communication takes time and can fail
You cannot have perfect consistency, availability, and partition tolerance simultaneously
Interfaces and protocols prevent chaos
Graceful degradation beats complete failure
Everything is part of something bigger

Wrapping Up

Distributed systems aren't magical - they're the natural evolution of any system that grows beyond what one component can handle. You already understand the concepts because you navigate distributed systems every day.

The next time you're designing a system, remember the restaurant analogy (or whatever system you know inside out) and try and translate their solutions to these problems to your use case. Start simple, add complexity only when needed, design for failure, and remember that everything is connected to everything else.

Whether you realised it or not, you've been working with distributed systems all along. Now you know why they work the way they do.

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

Beyond the code — Sun, 17 Aug 2025 17:10:10 +0000

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.

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

Beyond the code — Sun, 17 Aug 2025 16:59:51 +0000

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:

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.
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.

Coder, Developer, Engineer — What’s the Difference, Really?

Beyond the code — Mon, 02 Jun 2025 05:02:39 +0000

Hey again! This is post number two in my blog, Beyond the Code. Since it’s still early days, I’m keeping things high-level — these are the kind of reflections I wish someone had shared with me when I was starting out.

You’ve probably seen people throw around titles like coder, developer, and engineer like they’re interchangeable. Sometimes they are, depending on the context. But today, I want to talk about these terms not as job titles, but as mindsets.

Because the way you see yourself — and the level of professionalism you bring to the table — matters more than what’s printed on your LinkedIn profile.

👾 The Coder: Getting It Working (and Moving On)

Let’s start with the coder.

A coder is usually someone who’s comfortable writing code — maybe they’ve been learning in their spare time, building hobby projects, or playing with tools and frameworks. They might even be extremely sharp when it comes to the technical stuff — syntax, libraries, how a particular language works.

But what sets them apart is that they’re not really thinking beyond the code itself.

There’s often little thought given to test coverage, documentation, or readability. The goal is to make something work, not necessarily to make it maintainable or supportable. You’ll find a lot of "it works on my machine" energy here.

And that’s fine, to a point. It’s how most of us start. But if you’re aiming to be a professional, you don’t want to stop at just getting it working.

🧑‍💼 The Software Developer: A Professional with a Ticket

Now, a developer has levelled up.

They’ve made a career out of coding — maybe working freelance, or in a software house, or part of a product team. They take requirements, build features, and ship software. Job done, right?

Well… yes and no.

A good developer delivers working solutions. They’ll often write tests, do code reviews, and follow the team’s processes. But the focus is still mainly on getting the task done, not necessarily thinking about the system as a whole.

More often than not, the goal is to write code that’s “good enough” to pass review, get deployed, and move on to the next ticket. There’s often pride in the work, sure — but not always ownership of the wider picture.

🧠 The Software Engineer: Thinking in Systems

And then there’s the engineer.

A software engineer doesn’t just write code — they design solutions. They see their code as just one part of a living, evolving system. They ask tough questions:

What happens if this fails?
How will this scale?
Will someone else understand this in six months?
How can we make this easy to change later?

Engineers care deeply about things like testability, observability, concurrency, and clarity. They write code that’s meant to be read — not just once, but over and over by future maintainers (including their future selves).

They document decisions. They think about edge cases. They take pride in the craft of engineering, not just the shipping of features.

It’s not about writing more code or using fancier patterns — it’s about writing code that fits well into the system, and that leaves things better than they found them.

Which One Are You Becoming?

This isn’t about gatekeeping or job titles. It’s about intention.

Every coder can become a developer. Every developer can become an engineer. The path is open — but it does require effort. Not just technical growth, but learning how to think like a builder of systems. Like someone who takes real pride in their work.

If you want to be a true professional — someone others rely on, someone who builds not just software but trust — then the engineer mindset is where you want to head.

Final Thought 💬

There’s a quote I love (though I don’t know who said it originally — and I’m probably paraphrasing):

“Amateurs practise until they get it right. Professionals practise until they can’t get it wrong.”

Aim to be the kind of engineer who doesn’t just make things work — but makes them work well, reliably, and with care for those who’ll come after you.

See you in the next one 👋

How do you see yourself right now? Coder, developer, engineer — or somewhere in between? Drop a comment and let’s chat about it.

Welcome to Beyond the Code

Beyond the code — Sun, 01 Jun 2025 20:26:15 +0000

Hey there 👋

Thanks for stopping by — and welcome to Beyond the Code.

If you're a senior engineer already or someone who is working their way to the title, you're in the right place. This blog is for you.

Now, let me get one thing out of the way early on: this isn't going to be a blog full of code snippets and syntax deep-dives. Don’t get me wrong — I love writing code as much as the next developer. But there are already loads of great resources out there showing you how to write a for-loop, build an API, or configure a Docker container.

This blog is about everything else.

So, what is “beyond the code”?

It’s all the stuff that helps you grow from a coder into a well-rounded software engineer.

Things like:

Writing code that’s easy to maintain (and not just clever)
Communicating clearly with your team, your product owner, or even stakeholders
Giving and receiving feedback like a pro
Thinking in systems, not just lines of code
Understanding why that “quick fix” might come back to bite you later
Staying curious, staying relevant, and staying sane in a fast-moving industry You know — the real career-building stuff that often gets left out of tutorials

What to expect

Most posts will be short and focused, and I’ll try to avoid too much jargon or hand-waving. You can expect me to talk about:

Engineering principles that go beyond writing working code
System design and architecture (in a way that’s not intimidating, I promise)
Agile, lean, DevOps and what they really look like in practice
Team dynamics and communication — the stuff that makes or breaks real-world software projects
Personal growth, career paths, learning habits, and even the occasional thought on body language and presence in meetings (yes, really) Basically, if it’s helped me or someone, I know become a better developer or a better teammate, it’s fair game.

Let’s grow together

Whether you're still new to the industry or you've got a few years under your belt, I hope you find something here that makes you stop and think, try something new, or just feel seen.

And hey — if something sparks a thought or you’ve got your own experience to share, don’t be shy. I’d love to hear from you.

Let’s explore what it means to be a great software engineer — beyond the code.

See you in the next post.