Senior · Design · Streaming completion

Design a bounded consumer that publishes a batch only after a valid terminal record, and define behavior for error records, cancellation and truncated transport.

Think through your answer before opening the explanation.

Production engineering

Reveal answer and reasoning

A bounded consumer can decode records incrementally into a private staging owner, reject oversized lines or too many items, and require one valid terminal marker before publishing. Cancellation, transport failure and an error record leave the staged batch uncommitted. If individual effects must be applied eagerly, each effect needs its own replay and compensation contract; the terminal marker alone cannot provide atomicity across those actions.

A flushed server write does not prove that every byte reached the client or that a downstream consumer committed it. An aborted response may expose a partial prefix, raise a transport exception or do both at different layers. Error records also require a specified schema and ordering policy; their mere presence does not roll back an external effect already performed per item.

This classroom endpoint does not implement per-record size limits, a total byte budget or a resumable cursor. Its two fixed items bound the fixture, while a generalized streaming API needs explicit resource and recovery rules.

Report transport status, framing, terminal outcome and consumer publication separately. The normal two-item stream can satisfy this protocol; controlled error and abort cannot. The portable array test verifies only the explicit marker decision, while the external server supplies real response and connection behavior. A careful design also decides whether partial records may be shown provisionally, retained for retry or discarded.

Those decisions depend on the application, but they should never be inferred solely from an early200 header. The most useful interview answer identifies the exact completion boundary and the owner responsible for making it durable or visible.

What a strong answer covers

  • A bounded consumer can decode records incrementally into a private staging owner, reject oversized lines or too many items, and require one valid terminal marker before publishing.
  • A flushed server write does not prove that every byte reached the client or that a downstream consumer committed it.
  • Report transport status, framing, terminal outcome and consumer publication separately.

Common pitfall

A flushed server write does not prove that every byte reached the client or that a downstream consumer committed it. An aborted response may expose a partial prefix, raise a transport exception or do both at different layers. Error records also require a specified schema and ordering policy; their mere presence does not roll back an external effect already performed per item. This classroom endpoint does not implement per-record size limits, a total byte budget or a resumable cursor. Its two fixed items bound the fixture, while a generalized streaming API needs explicit resource and recovery rules.

Follow-up questions

  1. How would a resumed stream identify already applied records without turning a partial prefix into an automatic duplicate effect?
  2. What additional validation would a real NDJSON parser need beyond the portable item-prefix and last-marker check?

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