Otter.Ai Software Engineer Interview Experience — Rotting Oranges Plus a Meeting-Bot System Design

Coding round: Rotting Oranges

System design

Design a system: the user enters a video meeting link on a web page, the system assigns a bot from a Bot Pool, has the bot join the meeting, and continuously reports the bot's status back to the user.

The meeting platform could be Zoom, Google Meet, Microsoft Teams, WebEx, etc.

Existing components

Both ends of the system already exist:

Web UI

• user enters the meeting link
• user clicks a button asking the bot to join the meeting
• the page needs to show the bot's real-time status

Bot Pool

• contains a large number of bot instances that can join meetings
• may run on Kubernetes/EKS, EC2, or a similar compute cluster
• bots join meetings through a third-party meeting SDK

Design scope

Need to design all the infrastructure between the Web UI and the Bot Pool, including:

• receiving user requests
• asynchronously processing the task of joining a meeting
• finding and assigning an available bot from the Bot Pool
• managing bot states like idle and occupied
• Bot Pool capacity management and auto-scaling
• failure retries
• pushing bot status to the user in real time
• avoiding losing user requests if a service goes down

Functional requirements

Submit a meeting request
The user can submit:

• meeting URL
• optional meeting password or passcode
• user identity/auth info
  After the system accepts the request, it needs to arrange for a bot to join the meeting.

Async execution
Joining a meeting involves network calls with unpredictable latency, so the original HTTP request can't be made to wait until the bot successfully joins. The system should:

• accept and persist the task
• return to the client that the request was accepted, e.g. HTTP 202 Accepted
• assign and start the bot asynchronously in the background

Bot Pool management
The system needs to know:

• which bots are currently idle
• which bots are currently in a meeting
• how to atomically reserve a bot
• how a bot becomes available again after its meeting ends
• what to do when no bot is available

Real-time status updates
After the user submits the request, they need to keep seeing the bot's status, e.g.:

• Request accepted
• Waiting for an available bot
• Bot assigned
• Joining meeting
• Joined successfully
• Failed to join
• Disconnected
• Meeting ended
  On failure it also needs to return a specific reason, e.g.:
• invalid meeting link
• wrong password
• host rejected the bot from joining
• network error
• no bot currently available

Failure retries
The system needs to handle:

• the scheduling service crashing after it has already returned 202
• the Bot Manager being temporarily unavailable
• no idle bot currently available
• the bot failing to join the meeting
• a message getting consumed more than once
• the bot disconnecting mid-meeting
  Consider using a retry queue, delayed retries, and a Dead Letter Queue.

Non-functional requirements and scale

Scale given by the interviewer:

• peak of about 100,000 concurrent meetings
• about 1,000,000 meetings per day
• bot status doesn't need to be kept long-term after a meeting ends
• status updates need to be close to real-time
• the system needs to be fault-tolerant
• once the system has returned a success confirmation, the user's request must not be silently lost