Code to Architecture

Part 1 defined data ownership and failover authority. Part 2 moves closer to the client edge, because even a well-reasoned multi-region plan can still behave badly if producers and consumers do not fail over in a predictable way.

This is where client behavior becomes part of resilience design rather than a passive detail.

The Client-Side Problem

From the appl...

Part 1 forced the time model into the open. Part 2 is about what happens after that: once you choose event time, you still have to decide how much lateness you are willing to absorb, how long a window remains correctable, and what the system should do with data that arrives too late to include safely.

This is where a time model turns into a policy.

The Practical ...

Part 1 established the stateful baseline and made restore cost visible. Part 2 is where tuning becomes worth discussing, but only in relation to that baseline. Cache size, commit interval, and stream-thread count are not generic performance knobs. Each one shifts the balance between throughput, latency, and recovery behavior.

That trade-off is the real subject of this...

Part 1 made the case for version boundaries and a current in-memory model. Part 2 is about building the upcaster chain so that historical data can keep flowing without contaminating the whole application with version branches.

The important shift here is architectural. We are not just adding one conversion method. We are choosing where history gets normalized.

Wh...

Part 1 established the uncomfortable but useful truth: Kafka exactly-once semantics stops at Kafka’s boundary. Part 2 is what most real systems need next. If your processor writes to a database, cache, or external side-effect sink, you need an idempotent sink design that can absorb replay without corrupting state.

This is where the broader workflow becomes trustworthy...