Push based architecture vs pull based architecture

Photo by Jason Leung on Unsplash

Have you ever went on tiktok live and ever wonder why you can get updates so fast from other users messaging. Today we will talk about architecture practices that impact applications such as one that sees live updates.

Photo by Tim Mossholder on Unsplash

Push based architecture

Let’s imagine there is a tiktok live streaming a concert. There are at 10,000 people attending the concert online. What happens behind the scene is that there are 10000 clients connected to one server. In a push based architecture, the server gives constant data to these 10000 clients as soon as a message becomes available.

Well, how does a push based architecture gets implemented? There are two pieces to be considered:

• pub/sub: we have a publisher that publishes messages that we receive from a client. This client publishes a message and a subscriber that subscribes to the message will send this message across to other 10000 clients.
• websocket: multiple clients can set up real time connection with hosts that are subscribed to some pub/sub for real time updates. As the publisher sends message, all 10000 clients will get real time update immediately due to websocketing and the pub/sub system.

Well…what are pros and cons of this approach?

Let’s talk about the pros first:

• Reduced latency: we will always get updates in a much quicker manner than a system that does polling. Certain applications such as stock market applications like Robinhood and a chat application like facebook require immediate updates on data. Latency can be disasterous for an application like robinhood because users need to constantly know how the stock market is doing.
• Reduced network traffic: in a pull based architecture, the clients need to periodically pull data from the server. That can shoot network usage dramatically. In contrast, with a push based architecture, we only need to send data from the server to the clients only when there is an update.

Well…what about the cons?

• Network congestion: to be honest, there can be network congestion whether we are talking about a push based architecture or pull based architecture. Let’s imagine 2–3 people commented on a tiktok live session. Now the system has to be an update all the subscribers with the new message. This can burden the server tremendously.
• Scalability: what happens if there are more people subscribed to the server? What if multiple people are subscribed to multiple events? If this scales up, it can dramatically impacts the performance of the system.

To cope with the potential downfalls, we can compress data to reduce the size of the messages. We can also distribute the load on a load balancer as well.

Photo by Clem Onojeghuo on Unsplash

Pull based architecture

In a pull based architecture, data are being polled from the server on an interval. For example, in an application such as facebook or instagram, it will be polling for the latest feeds every 5 minutes, let’s say.

Well, what are the pros and cons of this approach comparing to a push based architecture?

Pros:

• ease of communication: the server does not have to worry about sending data to tons of client subscribers when message is ready.
• resource efficiency: depending on the scenario, pull based architecture can be less resource extensive than push based architecture. Imagine if there are 1 million users sending messages on a live comment application. With a push based architecture, that means the server have to feed the other clients the 1 million messages right away. That’s scary! In a pull based architecture, the messages are pulled later on which can ease the server in terms of work load.

How about its cons:

• latency: pull based architecture are not ideal for applications that require constant update, such as a live streaming video application or a live chat application.
• Caching difficulty: You cannot cache the messages if the client is polling in their own pace.