What SLOs should a market-data streaming pipeline have, and what does each protect?

The SLOs and what each protects

• End-to-end latency, at a percentile. From the event occurring to it being available to a consumer. Protects the product promise, and the percentile matters because the mean hides the tail that users notice.
• Consumer lag, per consumer group and per partition. Protects against a silent stall — a stopped consumer produces stale data with no error, and per-partition rather than aggregate because skew means one partition can be hours behind while the total looks fine.
• Completeness: the proportion of events that arrived, measured against a source count where one exists. Protects against silent loss, which is the failure mode nothing else detects.
• Freshness of the serving layer, which is what a consumer actually experiences and which differs from pipeline latency by the serving store's own write and index delay.
• Correctness of a sampled subset, compared against the authoritative source. Protects against a transformation bug, which produces plausible wrong values that latency and lag metrics cannot see.

What makes them meaningful

• Measured from the consumer's position, not the producer's. A pipeline that is fast and whose serving store is behind delivers a stale experience.
• Per data class, not globally. A price feed and a settlement report have completely different requirements, and one SLO across both is either unaffordable or useless.
• With a defined behaviour on breach: shed, conflate, degrade, or alert — decided in advance rather than at the moment.

The market-data specific requirement

Staleness must be visible in the product. A price displayed without an indication that the feed is delayed invites users to trade on it, and in a financial product a user who acted on data you knew was stale and did not disclose has a legitimate complaint.

The degraded state must therefore be a designed part of the interface rather than an error screen — because it will be seen regularly, since the dependency's degradation correlates with the volatility that drives user demand.

The one that is usually missing

Completeness. Latency and lag are measured because they are easy; whether every event arrived is measured rarely and is the failure that costs most — a silently dropped batch produces a chart that looks fine and is wrong.