Analytics Event Fan-Out: One Click, Seven Consumers, A Hundred Edge Cases

There is a moment in every product's life when one user click stops being one row in one table and becomes the entry point of a pipeline. This is not the same problem as transactional side effects, where the system needs to keep its own internal state consistent. This is fan-out for observation: one event, captured once, replayed into every system in the company that wants to learn from it.

The fan-out usually goes to predictable places. A dashboard wants near real-time aggregates. A fraud model wants the event within seconds for inline scoring. A feature store wants it pre-joined with user context for training. The data warehouse wants it in nightly batches with full history. A recommendation pipeline wants it for daily model refresh. An alerting system wants anomaly detection on top of the stream. Each of those consumers has its own latency target, its own retention need, and its own definition of correct.

That is the productivity gain of an event pipeline. You write the producer once. Consumers subscribe later, often built by teams that did not exist when you wrote it. But that flexibility is also the source of every operational pain you will spend the next two years debugging.

Schema evolution is the first wall. The producer team changes a field name. The dashboard updates immediately. The fraud model crashes silently. The warehouse keeps loading nulls into the new column for three weeks before anyone notices. Schema registries, additive-only changes, and explicit deprecation windows are how teams stay sane.

Lag is the second. Each consumer reads at its own speed. A slow consumer falls behind the head of the log. If retention is seven days and the consumer is eight days behind, you have lost data the consumer was supposed to process. Per-consumer lag dashboards are not optional.

Retries and dedup are third. At-least-once delivery is the realistic default in any production stream. Every consumer needs an idempotency key, or it needs to be designed so reprocessing the same event produces the same result. Dashboards that just count events double-count after a partition rebalance unless they dedup.

Ordering is the fourth and most subtle. The fraud model needs strict per-user ordering. The dashboard does not care. The warehouse can sort at read time. Ordering is expensive, so you spend it only where it matters, usually by choosing partition keys deliberately and accepting global disorder elsewhere.

The pattern is powerful precisely because it decouples production from consumption. Just remember that the decoupling is what creates the cost.