System requirements

Functional:

• support various genres
• real-time interaction
• content moderation
• audience engagement tool like live chat, pools, reactions, Q&A (reaction only for this case)
• streaming from a video / audio source
• user authentication
• configuration settings

Non-Functional:

• high availability
• high scalability

Capacity estimation

• 300,000 concurrent users
  • total requests = 300 000 users * 1 requests /120 seconds = 2500 requests per second
  • 5 interactions per minutes:
    • 300 000 * 5/60 = 25000 requests per second
• monthly average of around 50,000 concurrent users.
• Total RPS: 25000 + 2500 = 27,500 rps

• User Sessions: 76.3 GB
• Video Buffers: 10 GB
• Chat Data Storage: 4.5 GB
• Cache: 7.6 GB

Total Memory Requirement ≈ 98.4 GB

API design

• GET v1/genres/{genre}
  • response: list of stream
• POST v1/stream/create
  • request: userId
  • response:
    • HTTP Code
    • streamID
• POST v1/stream/start
  • request: streamID
  • response: HTTP code
• POST v1/stream/stop
  • request: streamID
  • response: HTTP code
• GET v1/stream
  • request: streamID
  • response: HTTP code, CDN link
• POST v1/reactions
  • request:
    • streamID
    • reaction
    • timestamp
  • response: HTTP code
• GET v1/reactions
  • request:
    • streamID
  • response: HTTP code
    • list of reaction
• POST user/login
  • request:
    • userID
    • password
  • response: HTTP Code

Database design

NoSQL

user:

{ userId, username, email, avatarURL, lastActive, sessionId}

stream:

{ streamID, streamName, timestamp, duration, status(live/offline), hostUserId, viewCount, starttime }

interaction:

{ reactionID, streamID, timestamp, userId, reactionType (enum)}

High-level design

see diagram, connect CDN to websocket server.

Request flows

• GET v1/genres/{genre}:
  • send request to stream server
• POST v1/stream/create
  • goes to stream server and identity server
  • update stream database
• POST v1/stream/start
  • create a websocket for the stream
  • update stream database
• POST v1/stream/stop
  • delete the websocket for the stream
  • update stream database
• GET v1/stream
  • subscribe to the websocket of the stream if stream is live, otherwise get from history server
• POST v1/reactions
  • goes to stream server, websocket server
  • add to interaction database
• GET v1/reactions
  • goes to stream server, websocket server
  • get from interaction database
• POST user/login
  • send request to stream server
  • check valid user with identity management server, return to stream server

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

used redis pub/sub channel here for fast interaction during streams.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?