System Object

LiveBoard is best understood as a product surface wrapped around an operation-processing core. The visible application has two major user spaces: the dashboard, where canvases and folders are managed, and the editor, where one canvas is edited collaboratively. The backend owns identities, sessions, access, canvas state, history, revision numbers, folder structure, and validation. Redis owns only ephemeral coordination for scaled backend replicas.

That division is the through-line for the system. The application has to feel immediate while people drag objects, move cursors, and change styles, but it also has to converge to one saved canvas after reconnects, rate limits, missed messages, and multiple backend servers. LiveBoard handles that by treating every user-visible edit as either a temporary preview or a durable operation. Temporary state can be fast and disposable; durable state has to pass through one ordered backend path.

The intended product setting is a focused working session: a small group of authenticated collaborators sketching diagrams, reviewing ideas, or arranging notes while talking elsewhere. LiveBoard optimizes for a shared editable canvas that can be reopened later, not for a public infinite whiteboard with anonymous links, asset uploads, export pipelines, or thousands of simultaneous cursors.

The important separation is durable versus transient state. PostgreSQL stores users, session tokens, canvases, folder rows, membership rows, operation logs, and undo/redo history. Redis stores cross-process Pub/Sub messages, presence TTL records, invalidation messages, and fixed-window rate-limit counters. React state stores the current view, selected ids, toolbar defaults, temporary drag and color previews, modal state, and local viewport.

That separation gives a simple rule for reading the rest of the paper: if losing the data would change the saved canvas, it belongs in PostgreSQL; if losing it would only make the live room briefly less smooth, it can live in Redis or browser memory. This rule explains why previews, cursors, and presence are treated differently from committed shape edits and history entries.

The runtime diagram is a failure map. If a browser refreshes, the canvas returns from PostgreSQL. If a Redis Pub/Sub event is missed, the next revision gap causes the client to refresh from PostgreSQL. If one backend replica dies, sockets reconnect through the proxy to another replica that shares the same database and Redis coordination layer. The fastest paths improve latency, but correctness falls back to durable state.