Why I chose
append-only events
Operational telemetry is easier to trust when the system records what happened instead of constantly rewriting the present.
An append-only event model is a good fit for OpenTrace because background work is naturally temporal. A job starts, moves through phases, reports counts, emits notes, hits milestones, and finishes. Those facts form a timeline.
If the system only stores current state, it loses the story. The latest value may tell you that 80,000 records were processed, but it does not show when the rate changed, when validation started, or which warning appeared before the final failure.
History is operational context
Append-only storage preserves context without requiring every producer to understand a complicated state model. Producers just say what happened. The UI can decide how to summarise, group, chart, or filter those events later.
Simple writes, flexible reads
The write path stays simple: validate the request and append the event. That simplicity matters for reliability. It also keeps room for new views over the same data, such as incident timelines, progress summaries, or drift reports.
The trade-off
Append-only systems need retention and summarisation decisions. That is a reasonable cost for a telemetry product whose main job is to explain what happened. The alternative is throwing away the timeline too early.