Benjamin Cane

#Bengineering 🧐

Short-form distributed-systems tradeoffs, reliability patterns, lessons learned, and leadership notes β€” shared weekly.

38 posts August 8, 2025 β†’ April 30, 2026
Portrait of Benjamin Cane

Subscribe to:

#Bengineering 🧐

Prefer your posts in a reader? Subscribe to the RSS feed or catch me on LinkedIn.

RSS Feed LinkedIn

Latest Drop

Portrait of Benjamin Cane
Benjamin Cane
April 30, 2026

Deterministic routing is one of the most effective ways distributed systems reduce consistency problems at scale.

It is a foundational technique used by many modern databases, caches, and large-scale platforms. Understand how it works and you can apply the same pattern in your own systems.

πŸ€” Understanding the Problem

At some point, every successful system hits the limits of a single database instance.

A single server can only handle so many connections, queries, writes, storage capacity, or CPU/memory demands. Even with the best hardware, performance eventually degrades. So systems scale horizontally.

Instead of sending all traffic to a single database server, requests are distributed across multiple nodes.

At the same time, resiliency matters. If one server fails and all data resides there, the outage can be severe.

So modern databases spread data across multiple nodes, availability zones, and regions.

Distributing load and data solves both capacity and resiliency problems. But it introduces another challenge.

How do you keep request behavior consistent when data is distributed across multiple systems?

⚠️ Why Replication Is Not Enough

Replication helps, but it does not solve every consistency problem.

Imagine a write lands on Server 1. Immediately after, a read request for the same data lands on Server 67. Will Server 67 have the latest version? Maybe, but often not.

Asynchronous Replication

With asynchronous replication, Server 1 will accept the write and replicate the data to other servers in the background. That means a follow-up read on any other node may return stale data.

Synchronous Replication

With synchronous replication, the write on Server 1 will wait for an acknowledgment from all replicas before returning a success. While this improves consistency guarantees, it increases latency.

The farther apart a replica is, the worse this gets. Local writes may be fast, but cross-region writes will be slow. Plus, is it really feasible to replicate data across every single node?

So the question becomes: How do you preserve consistency, without paying latency taxes?

πŸ”€ Route Requests to the Data

A highly effective answer is deterministic routing.

Instead of moving data to where requests might land, move requests to where the data already exists.

If requests for the same key can go to the same node, you gain predictable ownership, reduced stale reads, lower coordination overhead, and easier horizontal scaling.

πŸ‘¨β€πŸ« How Deterministic Routing Works

At a high level, the system needs a repeatable way to decide where requests should go.

A common approach is hashing.

  • A hash of user123 always goes to Node 7
  • A hash of user456 always goes to Node 42

As long as the same key produces the same result, requests can be consistently routed to the same owner. Many modern databases implement deterministic routing through techniques like consistent hashing, partition maps, and shard ranges.

πŸ—ΊοΈ Where Routing Logic Lives

Different systems solve routing in different places.

Client-side Routing

The client library knows the partition map and sends requests directly to the correct node. Used by many distributed caches and databases.

Proxy / Router Tier

A small router sits in front of nodes and forwards traffic appropriately. Useful when client behavior cannot be influenced.

Server-side Forwarding

Requests land anywhere, and the receiving node forwards internally to the owning node. Simple for clients, doesn’t introduce a proxy failure point, but introduces complex cluster discovery/health monitoring.

Each model has tradeoffs.

🧰 Routing Does Not Replace Replication

Deterministic routing is powerful, but not magic. What happens when the owning node is down? You still need replication.

Modern databases combine both: deterministic routing for performance and ownership, plus replication for durability and failover.

🧠 Why This Matters Beyond Databases

Distributed databases use this approach, but it is not unique to them.

Deterministic routing can be used to solve: session ownership, user affinity, in-memory workflow coordination, work queue partitioning, and more.

I’ve used deterministic routing many times to solve load distribution and consistency problems.

At scale, the answer is not always more/better hardware. Consistency and availability problems are not always solved with replication alone.

Sometimes the best answer is simply to send the request to the right place.

Previous Posts

  • April 23, 2026 When you think of microservices, you probably think of centralized shared services. But there's another valid pattern that is rarely discussed
  • April 16, 2026 Are you using traffic mirroring in production? If not, try it out.
  • April 9, 2026 Agent Skills Are Becoming the Best Way to Capture Institutional Knowledge

Archive

  • April 30, 2026
  • April 23, 2026
  • April 16, 2026
  • April 9, 2026
  • April 2, 2026
  • March 26, 2026
  • March 19, 2026
  • March 12, 2026
  • March 5, 2026
  • February 26, 2026
  • February 19, 2026
  • February 12, 2026
  • February 5, 2026
  • January 29, 2026
  • January 22, 2026
  • January 15, 2026
  • January 8, 2026
  • January 1, 2026
  • December 26, 2025
  • December 19, 2025
  • December 12, 2025
  • December 5, 2025
  • November 28, 2025
  • November 21, 2025
  • November 14, 2025
  • November 7, 2025
  • October 31, 2025
  • October 27, 2025
  • October 24, 2025
  • October 10, 2025
  • October 3, 2025
  • September 26, 2025
  • September 19, 2025
  • September 12, 2025
  • September 5, 2025
  • August 22, 2025
  • August 15, 2025
  • August 8, 2025

Made with Eleventy and a dash of #Bengineering energy.