How to redesign the database structure for a whiteboard so that 1000 users can draw without blocking?

To enable 1000 users to draw on the board simultaneously without locks, the database structure and data storage architecture need to be redesigned considering high concurrency and parallelism.

Main approaches:

1. Decomposition of data by regions (sharding by board area)

   • Divide the board into small independent segments (tiles, squares).
   • Store each segment separately so that changes in one segment do not block others.

2. Using event-driven approach and queues

   • Instead of direct database updates, save user actions in a queue (e.g., Kafka).
   • Asynchronously apply changes to the database, reducing locks.

3. Optimistic locking and versioning

   • Store versions of segments and merge changes in case of conflicts.

4. Using NoSQL or specialized storage

   • For example, document-oriented databases (MongoDB) or key-value stores (Redis) for fast updates.

5. Caching and periodic synchronization

   • Clients can work with a local cache and periodically synchronize changes.

Example of table structure for a relational database:

CREATE TABLE board_segments (
  segment_id SERIAL PRIMARY KEY,
  board_id INT NOT NULL,
  segment_x INT NOT NULL,
  segment_y INT NOT NULL,
  data JSONB NOT NULL,
  version INT NOT NULL DEFAULT 0
);

Each segment stores a piece of the board, and updates to a segment only modify the corresponding record. Clients send the expected version during updates to avoid conflicts.

This approach minimizes locks and allows scaling the board's work to a large number of users.