Design Anonymous Real-Time Pixel Canvases

Design real-time drawing on multiple fixed-size canvases. Users are anonymous, and each user operation may change only one pixel. Canvas creation is out of scope; focus on applying pixel changes and keeping viewers synchronized. ### Constraints & Assumptions - The source gives no pixel format, active-user count, update rate, persistence horizon, or conflict policy. - **Practice conflict policy:** the service assigns an authoritative order to accepted updates; for the same pixel, the latest accepted update determines its color. - A 4K-by-4K canvas is a storage example from the report, not a universal canvas size or evidence that one particular database representation is invalid. - Anonymous participation does not imply unlimited trusted writes. Define a lightweight connection/session identity for coordination without requiring a named account. ### Clarifying Questions to Ask - What pixel/color format and canvas dimensions must be supported? - Must an acknowledged pixel change survive a server failure? - How should conflicting updates to one pixel be ordered, and must all viewers observe the same intermediate sequence? - Do viewers subscribe to an entire canvas or only a visible region? ### Part 1 — Apply and Broadcast Pixel Updates Describe update validation, authoritative ordering, acknowledgments, and delivery to connected viewers. Explain concurrent writes to the same coordinate. #### What This Part Should Cover - Canvas, coordinate, color, and operation identity. - An ordering/commit boundary that defines the accepted pixel state. - Bounded fan-out, duplicate handling, and slow-client behavior. ### Part 2 — Store and Recover Canvas State Compare one database row per pixel with packed or tiled snapshots plus updates. Explain how a new or reconnecting viewer receives a consistent snapshot and catches up on later changes. #### What This Part Should Cover - Logical pixel state versus its physical representation. - Storage-size reasoning for the 4K example and update amplification trade-offs. - Snapshot/version boundaries, update-log retention, and gap recovery. ### Part 3 — Scale Multiple Canvases Describe partitioning, hot canvases or tiles, and anonymous-client abuse controls without adding canvas-creation features. #### What This Part Should Cover - Placement and ownership for independent canvases. - Trade-offs when a single canvas requires partitioning. - Admission and rate controls that protect drawing and broadcast capacity. ```hint Separate the snapshot from the update stream A viewer loading a snapshot can miss changes made during that load unless both the snapshot and later deltas share a version boundary. ``` ### What a Strong Answer Covers - Correct single-pixel updates and convergence of live viewers. - A justified storage representation rather than an assumption that many logical pixels imply too many database rows. - Recovery, fan-out, and partitioning appropriate to measured canvas activity. ### Follow-up Questions - How would reconnecting clients recover when their last update sequence is older than retained deltas? - What costs change if every pixel update rewrites an entire compressed canvas? - What guarantee is lost if tiles use separate ordering authorities instead of one canvas-wide sequence?