Designing an Online Code Editor [IDE]

Breakdown of the Parts of the System

In this blog, we will be breaking down how you'd ideally design an online code editor which has multiple users using it at the same time and sometimes the same editor is being used by multiple people. This code editor should also edit and compile the code perfectly with enough feedback to the user about errors/logs or success messages in the case it executes successfully.

Identifying the problem

We will have the user write his code, upload it and using file I/O we read the user's code on the server side. However, this is a classical case of the Thundering Herd problem where it can become a lot for the server to handle.

Responding Quickly To User Requests

Another challenge we have to handle is to give quick responses to the user in the form of feedback from the server side. The request given back will generally contain the status of the code execution and the input received will be code text along with a unique ID depicting that this code is from a particular user.

The above problems In the backend can be solved by using a queue to isolate the requests sent by the user and isolate every single request inside a "container" which contains workers to run/execute the operations in the code (something like Celery for Python backends) which will also be asynchronous to prevent non-blocking execution of the user's code. We will be using containers mainly to create one minor container to execute code instead of following a virtualization pattern which tends to use a VM that proves to be very heavy at scale due to the requirement of creating a mini operating system in such systems which is overkill.

Once the code executes, we map the user's request ID to them with the response generated on the server's end. A minor thing to be considered in this pub-sub / queueing model is to assign a TTL to every single request and remove stale requests to avoid overloading the queue with dead requests.

Handling Dead Containers

As discussed above, we will be using containers individual to every user mapped to their IDs to execute code. We will need to handle the cases where containers break down due to one or the other reason. Restarting a container will be a very bad UX as we need the user to not have any hiccups after he has finished coding a lot and restarting will essentially wipe out his previous progress making it frustrating.

Therefore, we can have the containers do something like probing where it sends us its status updates (if it's up or down) automatically and what we can do is follow some sort of a rule where if it sends us 2 back to back failing status update, we replicate the user's data on a fresh container and map his userId to this new container from the older failing one to safeguard his progress and to avoid hiccups on his end.

Conclusion

Overall, this is a simple breakdown of an online code-compiling system that has multiple users using it. We will be using containers and some form of a queueing service to handle user inputs and to improve the UX in the case of a failing container, we need to smartly reassign another container to the user after confirming that the container hosting the user's code is down. I hope you guys liked this article!

P.S. This article doesn't cover the nitty-gritty details like Web Sockets, Sessions, User I/O efficient handling etc and these topics can be further explored by the user as per their liking.