Skip to content

CONCEPT Cited by 1 source

Landing latency

Definition

Landing latency is the elapsed time between a source-data event (e.g. a row insert / update / delete in the source database) and the corresponding row appearing in the consumer-visible target table of the data warehouse. It is the data-warehouse equivalent of an end-to-end latency SLI for a data pipeline.

In a CDC pipeline, landing latency = (time to emit the delta from the source) + (time to ingest the delta into the delta table) + (time to merge the delta into the target table) + (any queueing delays along the way).

Why it shows up as a migration criterion

Meta's three-criterion gating system for promoting a job between migration lifecycle phases includes landing latency as criterion #2:

"No landing latency regression is observed. The data delivered by the new system should exhibit improved landing latency, or at minimum, match the performance of the old system." — Source: sources/2026-05-12-meta-migrating-data-ingestion-systems-at-meta-scale

The criterion is framed as non-regression — improvement is the optimistic outcome, but the migration is allowed to be neutral on this axis. The motivation: downstream analytics, reporting, ML training, and product workflows all have freshness-dependent behaviour — model-training pipelines that assume hourly target freshness will silently degrade if the new ingestion path lands data half a day later, even if every row is correct.

  • vs concepts/replication-lag: replication lag is between primary and replica of the same database; landing latency is end-to-end across the ingestion pipeline, including transforms and merges that replication lag doesn't see.
  • vs end-to-end request latency: request latency is per-request; landing latency is per-data-event, which may be batched or streamed.
  • vs freshness SLO: a freshness SLO sets a target landing latency; landing latency is the actual measured value.

Why the data-ingestion system needed "increasingly strict" landing latency

"As our operations grew in scale, our legacy data ingestion system began to show signs of instability under the increasingly strict data landing time requirements." — Source

The forcing function for the migration was that the legacy customer-owned-pipelines architecture could not consistently meet the tightening landing-latency requirements as Meta's source-data volume + downstream-consumer demands grew — making landing latency both a criterion of the migration's success and one of the reasons the migration was needed in the first place.

Seen in

Last updated · 542 distilled / 1,571 read