Katkat
Back

Design a Cloud IDE With SSH Access Where One or More Users Share a Host

OpenAISoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

A system design question about building a cloud IDE in which developers get SSH access to remote development hosts, and a host can be used by one person or shared by several. It tests host lifecycle management, connection routing through a gateway, workspace persistence, multi-user access control and isolation.

Design a cloud IDE: a service that gives developers a development environment on remote machines instead of their own computers. Developers connect to a remote host, edit and build code there, and run commands in a terminal.

The prompt left the requirements open, and the design was scoped to an SSH-based version. A user gets SSH access to a remote development host, and one host can be used by a single person or shared by several people.

Constraints and Clarifications

  • The scope is SSH access to a remote Linux host: terminal sessions, plus any editor tooling that runs over the same connection. A browser-based editor with real-time co-editing is not required unless you add it as an extension.
  • A host belongs to one user or is shared by several users at the same time.
  • Scale, machine sizes, regions and cost targets are not given. State your assumptions.

Clarifying Questions

  • When several people share a host, do they share one account and one set of files, or does each person get their own account and home directory on it?
  • Should a host keep running when nobody is connected, or stop after a period of inactivity and start again on the next connection?
  • What must persist across a host restart: only the files, or also installed packages, running processes and open terminal sessions?
  • How do users sign in, and who may invite others to a host?
  • Are the users employees of the same organizations, or members of the public whose hosts must be strongly isolated from each other?

Hints

Hint 1

Separate managing hosts from carrying sessions: Creating, starting, stopping and sharing a host is a different problem from carrying a user's live terminal traffic to it. Decide which component owns each.

Hint 2

What survives a host: Decide what a user expects to find after the host they were using is stopped, crashes or is replaced, and where that state must live.

Hint 3

Sharing is a permission, not just a connection: When a second person joins a host, decide how they are authenticated, what they may do there, and how the owner can revoke their access.

Follow-up questions

  • The owner of a shared host removes a collaborator who is in the middle of a session. What happens to that collaborator's open connections and running processes?
  • Connecting to a stopped host takes too long. How would you shorten the time to a usable shell?
  • The physical machine under a running host fails. What does the user see, and what do they lose?
  • How would you let a user open, in their browser, a web server running on their host, without exposing it publicly?