Code to Architecture

Part 1 is about drawing the first boundary correctly. Idempotent producers are extremely valuable, but they solve a narrower problem than many teams assume. They suppress duplicate appends caused by producer retries. They do not magically make a distributed workflow exactly-once.

That difference matters in production because the config is easy to enable, the guarantee...

Part 1 is about getting honest about the trade-off. A Kafka partition key is not a minor producer detail. It decides where ordering exists, where load concentrates, and which customers will be first to feel pain when traffic becomes uneven.

In this first pass, we deliberately do not “fix” hotspots. We establish the baseline keying model, measure skew, and make the ord...

Performance work goes wrong most often when profiling, benchmarking, and production telemetry are treated as if they answer the same question.

They do not.

profiling tells you where the time or allocation is going benchmarking tells you whether one isolated implementation is better than another production telemetry tells you whether the user-visible system ac...

Distributed locks are easy to overtrust because they resemble local mutexes in API shape while behaving very differently under failure.

The important mental model is not “global synchronized.” It is “lease-based coordination under uncertain clocks, pauses, and network conditions.”

That changes what a safe design looks like.

When a Distributed Lock Is Ac...

The outbox pattern exists because dual writes fail in ordinary, boring ways.

If a service commits business state to the database and then separately publishes an event, there is always a gap where one succeeds and the other does not. The outbox turns that one hard cross-system problem into:

one local transaction one replayable publication step

That is why...