Beyond the Canvas: The “Just Use Kafka” Trap

Abdul Basit — Thu, 21 May 2026 15:23:20 +0000

Why slapping a message queue between microservices doesn’t fix your architecture.

In almost every system design interview, there is a moment where a candidate realizes two microservices are too tightly coupled. Their immediate reflex? Draw a box in the middle and confidently declare,

“We’ll just put Kafka here to make it asynchronous.”

They sit back, thinking they just achieved perfect decoupling. The interviewer secretly writes down a red flag.

In big tech, an event stream isn’t a magic wand, it is a massive operational liability. If you want to clear a senior or staff loop, you have to stop treating message queues like a black box and start designing for asynchronous failure.

Here are 3 ways to show true depth when introducing a message queue:

The Poison Pill Problem: What happens when your consumer crashes every time it tries to process a corrupted data payload? If you don’t explicitly design a Dead Letter Queue (DLQ), that single bad message will endlessly retry, blocking the entire partition and bringing your downstream service to a grinding halt.
The Ordering Illusion: Candidates naturally assume messages are processed in the exact order they are sent. In a distributed queue with multiple consumer instances, race conditions are guaranteed. Tell the interviewer exactly how you will handle out-of-order execution — like using deterministic routing keys to bind specific data (like a user_id) to a single, strict partition.
Surviving Consumer Lag: When your downstream database goes offline for 5 minutes, your queue backs up with millions of pending events. When the database finally comes back online, your consumers will aggressively try to process that massive backlog, effectively DDoS-ing your own database. Stand out by introducing backpressure and rate-limiting at the consumer level.
Moving Beyond the Whiteboard
Adding a tool to an architecture diagram doesn’t magically remove complexity; it just shifts the friction somewhere else.

If you are ready to stop dropping buzzwords and start mastering the real-world mechanics of system design, let’s build together at Levelop.dev.

The Hidden Traps of Database Sharding

Abdul Basit — Tue, 19 May 2026 04:38:07 +0000

Moving past the textbook blueprint to handle millions of concurrent database writes.

When an interviewer asks you to scale a high-traffic application like a global order management system the generic playbook tells you to simply shard your relational database by user_id.

On paper, splitting your data across multiple database instances looks like a clean, linear way to scale writes. But in production, an unoptimized sharding strategy will introduce severe architectural friction.

If you want to clear a staff loop, you cannot just state how you shard; you must prove you can navigate the architectural fallout of that decision.

Here is how you deep dive into a sharding bottleneck:

The Hotspot Hot-Take: Sharding by a simple metric like tenant_id or location_id creates massive data skew. A single celebrity user or a major corporate client will route all traffic to a single shard, completely knocking it offline while other shards sit idle. Stand out by proposing a composite sharding key combining tenant_id with a deterministic hash of the created_timestamp—to evenly distribute the systemic shockwave.
The Cross-Shard Join Tax: The moment you split data across physical nodes, standard SQL JOIN operations become impossible. If a business query requires data residing on Shard A and Shard B, you force your application layer to fetch both datasets and perform an expensive in-memory merge. Explicitly tell your interviewer how you will avoid this by selectively de-normalizing your read models using an asynchronous event worker.
Designing for the Re-Shard: Systems grow. When Shard 3 reaches 90% capacity, you have to split it. If your system relies on simple modulo routing (hash(key) (mod N)), changing the number of shards (N) means you have to migrate 90% of your entire database across the network. Win the interview by introducing Consistent Hashing from day one, ensuring that adding a new node only requires moving a tiny fraction of your data.
Moving Beyond the Whiteboard
Real-world database architecture isn’t about choosing between SQL and NoSQL, it’s about managing data gravity, network hops, and physical constraints under heavy load.

If you want to stop copying abstract templates and start mastering the concrete mechanics of high-level design, let’s build together at Levelop.dev

DEV Community: Abdul Basit

Beyond the Canvas: The “Just Use Kafka” Trap

The Hidden Traps of Database Sharding