Metrics Ingestion · Approach

01 · Develop the design

Plan the design

Validate tenant-scoped batches, append them to a durable partitioned log and asynchronously index time series. Quotas, deterministic sample identities and retention control the service’s operating envelope.

Stage 1

Separate acceptance from indexing

An ingestion API validates and durably appends. Workers build the queryable representation asynchronously, so ingestion success and query visibility differ.

Stage 2

Budget series, not just bytes

Canonicalize labels and bound key count, value length and active series per tenant. Reject unbounded user-ID labels before they exhaust indexes.

Stage 3

Choose late-data semantics

Define allowed timestamp skew and a lateness window. Deduplication and rollups need deterministic behavior when a sample is replayed.

02 · Work through the method

Step-by-step approach

Authenticate the tenant and bound request bytes, sample counts, label counts and timestamp skew. Canonicalize labels into a tenant-scoped series identity and enforce active-series admission quotas.
Append accepted batches durably, partitioned by series identity for useful local ordering. Acknowledge append success and return retryable failure when admission or storage is unavailable.
Workers upsert samples using (tenant, series, timestamp). For this exercise, accept an identical duplicate and reject conflicting values for the same identity. Commit indexing progress only after durable writes; replay is then safe.
Query by tenant, bounded time range and selected series. Build rollups with idempotent bucket replacement and a defined lateness window. Retain raw and rolled-up data under separate policies and expose indexing lag.

03 · Justify the choices

Why this approach works

When should ingestion acknowledge a batch?

After validation and a durable log append

Durable acknowledgement lets workers recover accepted data through replay.

What prevents a label explosion?

Per-tenant series/label quotas with bounded admission

High cardinality consumes index and memory resources even when sample payloads are small.

What policy should replay use for identical samples?

A documented series/timestamp identity and deterministic duplicate handling

Replay and client retries can duplicate samples; identities and aggregation semantics must be explicit.

04 · Plan the evidence

Validation strategy

A worker crash followed by replay does not double-count samples.
A tenant exceeding active-series quota gets a bounded rejection.
Late/conflicting samples follow the stated ingestion policy.
Tenant-scoped queries cannot read another tenant’s series.

Trade-offs to explain

Asynchronous indexing improves ingestion isolation but introduces query-visibility lag.
Rejecting conflicting same-timestamp samples simplifies replay but needs clients to respect the sample identity contract.
The generic capacity tool does not model time-series compression, cardinality, log bandwidth or aggregation cost.