Search Indexing Service  ·  View 05 of 21  ·  People and journeys

Journey — A Merchant Publishes a Change

The one user who checks immediately, and why they do not get to set the freshness budget for 80 million documents.

Editable source SVG draw.io All views
Merchant one shop, phone Goal — Drop the price before the evening rush and know it took Trigger — Quiet hour, stock to move Done when — Searches their own shop, sees the new price 1 · Edit merchant console 2 · Save 3 · Check ◆ moment of truth 4 · Wait 5 · Believe What they do Changes price Taps save Searches own shop Refreshes Stops checking What answers Merchant service Change log commit Owner-write overlay Fast lane writer idx_v41 How it feels Confident Unsure Distrusts Where it hurts Old price still shown No idea how long What the design owes Ack on durable commit Read-your-writes ≤ 1 s Freshness in response Fast lane, not a rebuild Journey — A Merchant Publishes a Change The one merchant who checks sets the read-your-writes requirement — not the freshness budget for 80 M documents. v 1.0 · owner Data Platform Architecture

What the trough tells the architecture

  • The dip is at 'check', seconds after the save: the merchant searches their own shop and sees the old price. Read-your-writes for the owner is a 1-second requirement.
  • It is answered by an overlay in the query service reading a short-TTL recent-writes table — not by making the index itself that fresh, which would cost the platform its write-path economics.
  • The second dip, 'wait', is an information failure rather than a latency one: the response carries its observed freshness so the console can say how long.

Decisions

  • The source is acknowledged when the change is durable in the log, not when it is searchable — which is what keeps the accept path at a 50 ms p99.
  • The overlay applies the owner's own pending changes only. It is not a general consistency mechanism and is not offered to consumer queries.