Search Indexing Service  ·  View 02 of 21  ·  Context and scope

High-Level Architecture

Seven stages from a committed change to an answer, with the alias and its gate sitting between the index and the reader.

Editable source SVG draw.io All views
Capture Change Capture streams + push API Change log Change Log MSK · 7 d replayable Assemble Document Assembly join · fan-out · enrich Assembly State DynamoDB Write Fast Lane Writer partial update Slow Lane Writer whole document Index idx_v41 (live) OpenSearch idx_v42 (building) reindex target Alias Alias + Swap Gate the only contract Answer Query Service pre-filter · cursor gated swap High-Level Architecture — Change to Searchable, and Index to Answer Interface / broker Queue / topic Application we own Data store synchronous event / async The swap gate sits between the index and the reader: no reader ever names an index. v 1.0 · owner Data Platform Architecture

Decisions

  • The change log, not the index, is the platform's own system of record for what changed; everything to its right is rebuildable.
  • Two writers, not one: a fast lane doing partial document updates and a slow lane writing whole documents.
  • A second index is a normal operating state, not an incident: idx_v42 builds while idx_v41 serves.
  • The reader's contract is the alias. No consuming product ever learns an index's real name.

What this view omits

  • The control plane — definitions, aliases, judgement sets — which view 7 and view 8 carry.
  • Reindex orchestration, drawn properly in view 14.

Risks

  • The log is now a recovery-throughput commitment: if replay cannot rebuild the largest index inside the RTO, the whole boundary is decorative.
  • Two lanes mean two consistency stories inside one document, and a reader that cannot tell which field came from which.