Architecture Nugget - Feb 13, 2025

Learn AI in 5 minutes a day

This is the easiest way for a busy person wanting to learn AI in as little time as possible:

1. Sign up for The Rundown AI newsletter

2. They send you 5-minute email updates on the latest AI news and how to use it

3. You learn how to become 2x more productive by leveraging AI

Sign up to start learning.

8 Must-Know Distributed System Design Patterns

This article covers eight key design patterns used in distributed systems to help build solutions that scale, recover, and stay up and running. Here’s the lowdown:

• Ambassador: Offload non-core tasks—like retries and timeouts—to a helper service so your main service can focus on what it does best.

• Circuit Breaker: Stops your service from repeatedly calling a failing dependency. It watches for too many errors, then temporarily blocks calls until things get better.

• CQRS: Splits operations into two lanes: one for writing (changing data) and one for reading (retrieving data). This separation boosts performance and keeps things simple.

• Sharding: Breaks a big database into smaller chunks (shards) spread across multiple servers. Each shard handles its own piece of the puzzle, making the system more scalable.

• Sidecar: Runs extra components alongside your main service to handle tasks like logging and monitoring, keeping the core service lean and focused.

• Pub/Sub: Lets different parts of your system talk to each other asynchronously using messages. Publishers send messages to a channel, and subscribers pick them up, keeping everything decoupled.

• Leader Election: Makes sure only one node takes charge of coordinating certain tasks, avoiding conflicts and ensuring smooth operations.

• Event Sourcing: Instead of just storing the latest state, this pattern records every change as an event. This full history lets you rebuild or analyze the system’s state anytime.

How Distributed Systems Avoid Race Conditions using Pessimistic Locking?

In a distributed system, things can get a bit tricky when multiple processes try to update the same data at the same time—this is what we call a race condition.

Imagine two people trying to edit the same document at once; chaos, right? To avoid this mess, the article explains that a process will lock the shared resource before making any changes. This way, no one else can jump in until the update is finished.

Instead of the simple one-at-a-time approach in single systems, distributed systems use a cluster-wide lock database to keep track of who’s using what, ensuring everyone plays nice.

But locking isn’t enough on its own. What if a node freezes or takes too long to update?

That’s why each lock comes with a lease—a kind of time limit. Once the lease expires, the lock is automatically released, so no resource stays blocked forever. And to add an extra layer of safety, the system uses fence tokens. Each time a lock is acquired, a new token is issued.

If a node tries to update with an old token after its lease has expired, the update is rejected, preventing outdated changes from messing things up. This neat setup keeps the system orderly even when things don’t go as planned.