How would you define booking SLOs and add distributed tracing?

Say it in 30 seconds

Say it like this (20-30 seconds)

This is an explain-only extension; MiniTickets has correlation logs and infrastructure alarms, but no formal booking service-level objective (SLO) or distributed tracing. I would define a customer-visible success measure, its eligible requests and time window, then set a target with the product owner. Asynchronous ticket readiness needs a separate completion deadline. Traces would measure where latency occurs, while error-budget alerts would prioritize sustained user impact. Instrumentation must preserve privacy and remain affordable under sale traffic.

The deeper answer

A service-level objective is an agreed target for a measured user outcome. Define whether valid sold-out rejections count as successful service behavior; otherwise a popular event could appear less reliable merely because demand exceeded inventory. Separate availability from booking correctness, including duplicate or oversold bookings.

For asynchronous work, measure time from accepted booking to required ticket readiness, with a policy for failed and still-pending work. A request can return quickly while that completion objective fails. Propose durable timestamps and business counters before choosing numerical targets; this repository has no measured production baseline for them.

Tracing would propagate trace context across HTTP and message boundaries, retaining links for delayed or retried work. Current correlation IDs remain useful for logs but do not create spans. Keep metric labels to a small fixed set of values, avoid emails and raw tokens in attributes, and choose sampling that retains useful failures without uncontrolled storage cost. Trace instrumentation, SLO definitions and error-budget alerting are all proposed only.

Counter-questions

Would you use average latency as the objective?

An average can hide slow customers. Define a proportion of eligible operations meeting a deadline or an appropriate percentile, with a clear window.

What if the HTTP request succeeds but tickets arrive late?

The request objective can pass while the asynchronous completion objective fails. Track both outcomes explicitly.

Does sampling every error guarantee a complete trace?

No. Parts may already have been dropped upstream. Plan context propagation, sampling and retention together, and use logs and metrics as complementary evidence.

Where in MiniTickets

Read the path chapter, select the relevant map piece →, then inspect infra/src/observability/dashboard-body.ts → FOLLOW_ONE_REQUEST_QUERY.