The Problem 
 
The world is about to end, and the only way to save it is, of course, customer training. 
And what could be more integral and indicative to customer training than a very basic 
client-server application that relays data over WebSockets? 
So, as you can understand, we need a client-server application that relays data over WebSockets. 
Only when trainers all over the world could finally know what's going on with their students' 
training workspaces, could the world be relieved of the existential threat that's looming over it. 

The Service 
Background 
 
In this scenario, we have: 
● Events - these are live training events, to which the trainers and students enroll. 

● Workspaces - each trainer/student has their own workspace, associated with a single 
Event. 
 

At this stage, we want a service that lists for the trainer all of the workspaces of all events. 
This is how the data of a Event looks like: 

{
"id": "lkdrit3533",
"name": "Kibana Course"
}

 
 
This is how the data of a Workspace looks like: 

{
"id": "lkj54lkasd8",
"eventId": "4k5naskd83",
"owner": "jane@doe.com",
"status": "offline/preparing/ready/terminated/deleted",
"createdAt": "2018-08-09T18:13:00.294Z"
}

2 
 

Step 1 
● A client that gets the list of all of the Workspaces from a server in a real-time manner - i.e. 
over WebSockets. 

● The client should only display the list of Workspaces and their information. 

● The server should get the Workspaces from any kind of data source (a database, a REST 
service, a file, etc.). 

● The server should react to changes in this data source (keep the reactive part dead 
simple) and send all of the Workspaces to the client. 

● The client should react to the Workspaces sent by the server and display the updated list 
of the Workspaces. 

● You'd have to pick a library for the WebSockets part. Please thoroughly explain why you 
chose the specific framework you used. 

Step 2 
Now let's assume that we have a performance problem, and we don't want a client to get all of 
the Workspaces, but only those that belong to a single, specific Event. 
Suggest a feature that enables a client to register only to Workspaces that belong to a specific 
Event. 
 

Step 3 
We now understand that the last improvement didn't solve the performance problem. The 
payload of each Workspace is very big (let's assume there's a bit more in that JSON). We can't 
just send this whole payload every time a workspace changes. 
Suggest a solution to the problem. 

3