Real-time features in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to choose the main protocol used for real-time communication.

HLD

The system uses [1] protocol to enable real-time data exchange between clients and servers.

Drag options to blanks, or click blank then click option'

AWebSocket

BHTTP

CFTP

DSMTP

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing HTTP which is request-response only.

Confusing FTP or SMTP with real-time protocols.

WebSocket is the standard protocol for real-time, full-duplex communication between client and server.

2fill in blank

medium

Complete the code to select the component responsible for broadcasting messages to multiple clients.

HLD

In the architecture, the [1] handles sending real-time updates to all connected users simultaneously.

Drag options to blanks, or click blank then click option'

ALoad Balancer

BDatabase

CMessage Broker

DAPI Gateway

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing Load Balancer with message distribution.

Thinking API Gateway handles message broadcasting.

The Message Broker efficiently distributes messages to multiple clients in real-time systems.

3fill in blank

hard

Fix the error in the code to ensure the system supports horizontal scaling of real-time connections.

HLD

To scale real-time connections, the system uses [1] to share session state across servers.

Drag options to blanks, or click blank then click option'

ADistributed Cache

BSticky Sessions

CLocal Cache

DSingle Server

Attempts:

3 left

💡 Hint

Common Mistakes

Using sticky sessions which reduce scalability.

Relying on local cache causing inconsistent state.

Distributed Cache allows multiple servers to share session data, enabling horizontal scaling.

4fill in blank

hard

Fill both blanks to complete the real-time message flow code snippet.

HLD

Client sends a message via [1] to the server, which then publishes it to the [2] for distribution.

Drag options to blanks, or click blank then click option'

AWebSocket

BHTTP

CMessage Broker

DDatabase

Attempts:

3 left

💡 Hint

Common Mistakes

Using HTTP instead of WebSocket for real-time sending.

Choosing Database instead of Message Broker for distribution.

Clients use WebSocket for real-time sending, and the Message Broker distributes messages to subscribers.

5fill in blank

hard

Fill all three blanks to complete the code for a scalable real-time notification system.

HLD

Notifications are sent from [1] to [2] using [3] to ensure low latency and high throughput.

Drag options to blanks, or click blank then click option'

AClient

BMessage Broker

CWebSocket

DDatabase

Attempts:

3 left

💡 Hint

Common Mistakes

Using Database as the message distributor.

Confusing WebSocket as the sender instead of the delivery protocol.

Clients send notifications to the Message Broker, which uses WebSocket to deliver messages quickly.

Practice

1. Which protocol is commonly used to enable real-time communication in web applications?

easy

A. SMTP

B. HTTP/1.1

C. WebSocket

D. FTP

Solution

1. Step 1: Understand real-time communication needs

   Real-time apps require a protocol that supports two-way, instant data exchange.

2. Step 2: Identify protocol features

   WebSocket allows full-duplex communication over a single connection, unlike HTTP/1.1 which is request-response only.

3. Final Answer:

   WebSocket -> Option C

4. Quick Check:

   Real-time = WebSocket [OK]

Hint: Real-time needs two-way instant data flow: WebSocket fits best [OK]

Common Mistakes:

• Confusing HTTP with WebSocket for real-time
• Choosing FTP or SMTP which are not real-time protocols
• Thinking HTTP/2 is the same as WebSocket

2. Which component in a real-time system is responsible for distributing messages from producers to consumers?

easy

A. Broker

B. Producer

C. Consumer

D. Database

Solution

1. Step 1: Define roles in real-time messaging

   Producers send data, consumers receive data, and brokers route messages between them.

2. Step 2: Identify the distributor

   The broker acts as the middleman ensuring messages reach the right consumers.

3. Final Answer:

   Broker -> Option A

4. Quick Check:

   Message routing = Broker [OK]

Hint: Broker connects producers and consumers by routing messages [OK]

Common Mistakes:

• Confusing producer as distributor
• Thinking consumer sends messages
• Assuming database handles message routing

3. Consider a chat app using WebSocket. If the server receives a message from User A and broadcasts it to 100 connected users, what is the main bottleneck to scale this real-time feature?

medium

A. User A's device speed

B. Client browser rendering speed

C. Database read latency

D. Server CPU and network bandwidth

Solution

1. Step 1: Analyze message flow in real-time chat

   The server receives and then sends the message to all connected users, requiring CPU and network resources.

2. Step 2: Identify bottleneck

   Server CPU handles message processing; network bandwidth handles sending to many users simultaneously.

3. Final Answer:

   Server CPU and network bandwidth -> Option D

4. Quick Check:

   Scaling real-time = Server resources [OK]

Hint: Server resources limit broadcast scale, not client or DB speed [OK]

Common Mistakes:

• Blaming client device speed for server load
• Focusing on database latency which is less critical here
• Ignoring network bandwidth limits

4. A real-time notification system uses MQTT but users report delayed messages. Which is the most likely cause?

medium

A. Clients are using WebSocket instead of MQTT

B. Broker is overloaded and dropping messages

C. Messages are too small to send quickly

D. Users have disabled notifications on their devices

Solution

1. Step 1: Understand MQTT broker role

   The broker routes messages; if overloaded, it queues or drops messages causing delays.

2. Step 2: Evaluate other options

   Clients using WebSocket instead of MQTT would cause connection issues, not delays; small messages send faster; disabled notifications affect display, not delivery.

3. Final Answer:

   Broker is overloaded and dropping messages -> Option B

4. Quick Check:

   Delays usually mean broker overload [OK]

Hint: Delays often mean broker overload, not client protocol mismatch [OK]

Common Mistakes:

• Blaming client protocol mismatch for delays
• Assuming small messages cause delays
• Ignoring broker capacity limits

5. You are designing a real-time stock price update system for millions of users. Which approach best ensures scalability and low latency?

hard

A. Use a distributed message broker cluster with topic partitions and WebSocket connections

B. Store all prices in a single database and poll clients every second

C. Send updates via email to all users when prices change

D. Use HTTP long polling from clients to server for updates

Solution

1. Step 1: Understand scalability needs

   Millions of users require distributed systems to handle load and maintain low latency.

2. Step 2: Evaluate options

   Distributed brokers with topic partitions allow parallel processing; WebSocket supports instant push updates. Polling and email cause delays and high load.

3. Final Answer:

   Use a distributed message broker cluster with topic partitions and WebSocket connections -> Option A

4. Quick Check:

   Scalable real-time = Distributed broker + WebSocket [OK]

Hint: Distributed brokers + WebSocket scale best for millions [OK]

Common Mistakes:

• Choosing polling which wastes resources and adds latency
• Using email which is not real-time
• Relying on a single database causing bottlenecks