Push Pattern
What if we want a resource on the client side as fast as possible after some event happens that client isn’t aware about?
Intro
Request Response isn’t always perfect for certain workloads, especially when expecting real time updates like notifications on the client side. In that scenario we as a user don’t ask server for notifications — its not request response communication design pattern — but we still expect to receive resources when some kind of event happens, event that client isn’t aware about — backend is.
You might say, well we can always send request to the server every few seconds or so to maintain seemingly real time updates. But is that efficient? It will probably not scale really well.
What is Push?
It’s a system design pattern where data is actively sent (“pushed”) to a initiator (client) rather than having the initiator (client) poll or check for data periodically. You start by establishing connection and starting that moment initiator doesn’t have to do any other interaction with the receiver (server).
Pattern:
- We establish bidirectional connection between client and server
- Every time backend performs some kind of action we want to be informed about — message — the result is pushed to the client.
Where is it used?
The push pattern can be used in various ways:
- Event-Driven Systems — These systems are structured around the production, detection, consumption, and reaction to events. Here, an event producer will push events to consumers or handlers as they occur, rather than consumers continuously checking for new events.
- Push Notifications — Common in mobile and web applications, push notifications are messages sent by an application server to the client application, alerting the user of new messages or events without the user needing to open the application.
- Real-time Data Streaming — Applications that require real-time data updates, such as stock trading platforms or live sports scores, use push models to send updates to clients as soon as new data is available.
- Publish/Subscribe (Pub/Sub) Systems — In these systems, messages are published to a message broker or event bus, which then pushes these messages to subscribed clients. This decouples the message producers from consumers, allowing for scalable and flexible architectures.
The push pattern is advantageous in scenarios where timely delivery of information is critical, and it can reduce the overhead and latency associated with periodic polling.
However, it can also introduce complexity in handling the flow of messages, especially in high-volume or highly distributed systems, and may require more sophisticated error handling and backpressure strategies (mechanisms used to handle situations where data is being produced faster than it can be processed, by controlling the flow of data to prevent system overload or data loss).
Pros
- Realtime
Cons
- Client can’t be offline — connection must be active at the moment of pushing
- Client must be able to handle the received data — it doesn’t care if you do. What will happen if server sends too much information to the client and it won’t be able to handle it? It might crash :D
Cheers!
