Designing a Cloud-based Collaborative Whiteboard: Cloud & Distributed Server Architectures

Distributed State Management

You should evaluate available cloud and distributed server architectures before you design and implement your own distributed whiteboard system. You should have convincing reasons to justify the technology choices that you have made for your architecture.

In this task you should have a clear understanding and justification of the tools and technologies that you will use to implement your Cloud based Collaborative whiteboard.

The Cloud based Collaborative Whiteboard should allow multiple users to draw simultaneously on a shared interactive canvas.

When a new person joins the system the user should obtain the current state of the whiteboard so that the same objects are always displayed to every active user.

The system should support a single whiteboard that is shared between all of the clients. All the users should see the same image of the whiteboard and should have the privilege of doing all the drawing operations

When displaying the whiteboard, the user interface should show the usernames of other users who are currently editing the same whiteboard. Users must provide a username when joining the whiteboard.

Users should vote to elect a leader who then has the admin rights. A new leader should be elected using a consensus protocols (Paxos, Raft etc). This node/user essentially takes charge of the system,  we call this node the “leader”. When this node fails, then the system detects this and users should elect another node to take the leadership role.

The leader should allow only a selected group of users/peers to write/draw on the whiteboard at the same time. Other users who want to participate should wait in a queue to be given permission. All the peers will see the identical image of the whiteboard, as well as have the privilege of doing all the operations.

Only the leader of the whiteboard should be allowed to create a new whiteboard, open a previously saved one and close the application.

Replication

The copy of the whiteboard should be saved when all users have agreed to the whiteboard state that meets their requirements. This should be achieved through implementing a consensus protocol. The users/nodes/servers should respond with a “yes” or “no” vote regarding the transaction. If more than 50 percent servers respond with a “yes” vote, the leader issues a commit operation to the servers to make the transaction durable; i.e., the whiteboard state has been committed to all participating servers (strongly consistent vs loosely consistent).

Users should be able to work on a drawing together in real time, without appreciable delays between making and observing edits.

You can have multiple servers that communicate with each other or a single central one that manages all the system state.

You have to consider when/what messages are sent across the network because sending/receiving too many messages across users will have performance implications. This will require designing an exchange protocol that establishes which messages are sent in which situation and the replies that  they should generate.

You should create a Docker container for your cloud based whiteboard system and deploy it in the Docker registry or anther registry of your choice. You should share the client details on how to access your Docker container for the system so that we can test your implementation. All details accessing  and running your service should be written in step by step so that it only takes two minutes (max) to test the complete functionality.