Observe the connection lifecycle

A dashboard shows current connections, abnormal close codes, replay gaps, slow consumers, and the age of the newest delivered event. That contrast gives us something useful to test instead of a rule to memorize.

Request counts alone cannot explain a live system; you need connection and stream lifecycle signals. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can log every payload while omitting the metrics needed to spot a system-wide failure and still get one successful demo. Push past the demo. collect low-cardinality lifecycle metrics, structured errors, traceable ids, and redacted samples where they add evidence, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Ship a live feature that has limits, useful telemetry, a degradation path, and a repeatable failure test matrix. Save the before-and-after evidence now; it will make the final project review much more honest.

Create an alert for stale delivery and use the metrics to distinguish server silence from client reconnect failure. Save the evidence, then explain which requirement would force you to choose a different design.