Push model architecture in backend system

When discussing backend execution, the "Push" design pattern often goes overlooked despite its popularity in specific use cases. If your goal is to deliver responses to the client as quickly as possible or to achieve immediate results, the push model is one of the most effective patterns to implement. However, like any design pattern, it comes with its own pros and cons. Let’s dive into the details.

Why Push Over Request-Response?

The traditional request-response model is not always ideal for certain workloads, particularly those requiring real-time notifications. Consider scenarios like:

• A user logs into a system.

• A new YouTube video is uploaded.

• A new tweet is posted on Twitter.

In these cases, how does the client know that an event has occurred? The request-response model would require the client to repeatedly query the server (“Is there a notification?”), which is inefficient and does not scale well. The push model shines here by enabling the server to notify the client about such events as they happen.

What is the Push Model?

In the push model:

1. The client establishes a connection with the server.

2. The server sends data to the client without requiring a specific request.

This approach relies on a connection already being established, often through a bidirectional protocol. While unidirectional communication can work, bidirectional protocols (like TCP) are better suited for such scenarios.

Real-World Example: RabbitMQ and Push Notifications

RabbitMQ, a popular messaging system, uses the push model to distribute messages to connected clients. When a message is added to a queue, RabbitMQ immediately pushes it to all subscribed clients. This approach reduces communication overhead but requires careful management of connected clients to ensure scalability and reliability.

Contrast this with Kafka, which opts for a log-polling model where clients request messages at their own pace. Kafka’s approach is preferred in scenarios where clients need to control the load they handle.

Pros and Cons of the Push Model

Pros:

1. Real-Time Updates: Data is pushed to the client as soon as it becomes available.

2. Efficient Communication: Eliminates the need for constant client polling.

3. Perfect for Certain Applications: Ideal for chat apps, live notifications, and similar real-time use cases.

Cons:

1. Client Must Be Online: The client needs to be connected to the server to receive updates.

2. Scalability Challenges: Handling a large number of simultaneous connections can be resource-intensive.

3. Overwhelming the Client: Servers may push more data than the client can handle, potentially leading to crashes or performance issues.

4. Protocol Requirements: Often requires a bidirectional protocol like WebSockets.

Code Example: WebSocket Implementation

Here is an example of a WebSocket server and client implementation:

Server-Side Code (Node.js)

const WebSocket = require('ws');

const server = new WebSocket.Server({ port: 8080 });
const clients = new Set();

server.on('connection', (ws) => {
  clients.add(ws);

  ws.on('message', (message) => {
    console.log(`Received: ${message}`);
    // Broadcast message to all clients
    clients.forEach((client) => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });

  ws.on('close', () => {
    clients.delete(ws);
  });
});

console.log('WebSocket server is running on ws://localhost:8080');

Client-Side Code (Browser)

const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
  console.log('Connected to server');
  ws.send('Hello Server!');
};

ws.onmessage = (event) => {
  console.log(`Message from server: ${event.data}`);
};

ws.onclose = () => {
  console.log('Disconnected from server');
};

Explanation of the Code:

Server-Side Code:

• WebSocket Library: The ws library simplifies WebSocket protocol usage.
• Creating the Server: new WebSocket.Server({ port: 8080 }) initializes the WebSocket server on port 8080.
• Tracking Clients: A Set named clients is used to manage active connections.
• Event Handlers:
  • connection: Adds new clients to the clients set.
  • message: Broadcasts received messages to all connected clients, except the sender.
  • close: Removes disconnected clients from the clients set.

Client-Side Code:

• Connecting to the Server: new WebSocket('ws://localhost:8080') establishes a WebSocket connection.
• Event Handlers:
  • onopen: Logs the successful connection and sends a message to the server.
  • onmessage: Handles and displays messages received from the server.
  • onclose: Logs the disconnection event.

This implementation demonstrates how multiple clients can connect to a WebSocket server and exchange messages in real time.

Conclusion

The push model is an excellent design pattern for delivering real-time data in scenarios where immediate updates are critical. However, it’s essential to understand its limitations and use it judiciously. By leveraging tools like RabbitMQ and protocols like WebSockets, developers can build robust, scalable push-based systems tailored to their application's needs.

For hands-on implementation, you can explore building a simple WebSocket-based chat application—a practical way to understand the push model's power and nuances.