Casebook/Case 02
Data & platform

Chronon: feature definitions across offline and online paths

A reconstruction of how one feature definition can serve historical training joins and fresh online values.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Airbnb published Chronon as a feature platform with batch and streaming computation.

Its design emphasizes point-in-time-correct backfills and online serving from common definitions.

Read Airbnb Engineering — Chronon Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Historical correctness, late events, high-volume joins, freshness, and reuse across teams.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Offline metrics rise while production degrades because historical rows contain information unavailable at decision time.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Offline metrics rise while production degrades because historical rows contain information unavailable at decision time.

Investigation

Inspect entity keys, event time, processing time, mutation rules, windows, and online materialization lag.

DIAGNOSTIC EXERCISE

A refund occurred Monday but arrived Wednesday. Should it appear in a Tuesday training row, and why?

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

Duplicated feature logic and non-temporal joins allow current knowledge to leak into the past.

FIX

Compile shared feature definitions into point-in-time offline joins and online serving materialization.

Rollout

Dual-run existing and compiled features; compare values by entity, event time, and definition version.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • Copying SQL into each training job.
  • Comparing only aggregate feature distributions.
06 · Monitoring after the fix

Make recurrence visible early.

01

Point-in-time join invariants

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Online freshness lag

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Offline-online sampled parity

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

The feature definition is the product; stores and compute engines are implementations.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.