Senior · Design · Volatile publication is not a compound transaction

How would you publish a sequence of changing snapshots when consumers need a precise delivery contract?

Think through your answer before opening the explanation.

Runtime & concurrency

Reveal answer and reasoning

First decide whether consumers need the latest available snapshot, every accepted update, or merely eventual observation. For a latest-snapshot contract, publish an immutable versioned object through an appropriate reference protocol and keep its contents immutable after publication. For every-item delivery, a bounded channel with explicit completion and backpressure may be clearer. One reused boolean cannot encode an arbitrary history without additional state.

Test the chosen semantics with controlled producers and consumers, direct version or item expectations, and bounded termination. Keep actual storage or broker guarantees separate if state must survive processes. The wrong design repeatedly toggles a ready flag around mutable fields and assumes no generation can be missed or mixed. A passing fixture confirms its arranged case, while correctness also requires the documented memory ordering, ownership discipline, and an explicit answer to what happens when producers outrun or outlive consumers.

What a strong answer covers

  • Choose latest-state versus every-update semantics.
  • Publish coherent immutable state or use a delivery abstraction.
  • Specify progress, backpressure, and completion.

Common pitfall

Using one flag to promise complete multi-generation delivery without a state or ownership protocol.

Follow-up questions

  1. How would a slow consumer observe skipped versions?
  2. What changes if data must survive process failure?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions