What are the trade-offs between using push or pull models for event delivery?

1 Push model

The push model involves producers sending events directly to consumers or through a broker as an intermediary. This model is suitable for scenarios requiring low latency, high throughput, and real-time updates. However, the producers need to know the consumers or the broker, leading to coupling and reduced flexibility. Consumers must also handle backpressure, where they cannot keep up with incoming events, which may cause congestion, loss, or duplication of events. Additionally, they must implement idempotency to process the same event multiple times without side effects; this may increase complexity and cost of the logic.

2 Pull model

In the pull model, producers store events in a persistent storage such as an event store, and consumers query the storage for new events. Consumers control the pace and frequency of fetching events and process them at their own convenience. This model is suitable for scenarios where high availability, resilience, and eventual consistency are needed. However, it also has drawbacks; producers may experience latency, overhead, and failure points when writing events to the storage. Additionally, consumers may generate unnecessary traffic, waste resources, and miss updates when polling the storage. Lastly, consumers must handle concurrency when multiple instances of the same consumer access the same events, which can cause conflicts, inconsistencies, or duplicates.

3 Event store and projections

One way to address the trade-offs of the push and pull models is to use an event store and projections. An event store is a specialized database that stores events in chronological order, while a projection is a query that transforms events into a different representation. By using this approach, producers can write events to the event store without worrying about the consumers, decoupling them and increasing flexibility. Consumers can read events from the event store or from projections, providing them with options and reducing latency. Furthermore, consumers can subscribe to projections, enabling them to receive events in a push mode with more control and customization.

4 Trade-off analysis

When considering event delivery in microservices, there is no one-size-fits-all solution. You may choose to use the push model, the pull model, an event store, or projections based on your requirements. To decide which is best for you, ask yourself how important latency is for your use case, how reliable your network and infrastructure are, and how consistent your data and logic are. If latency is critical, the push model may be best; if frequent failures or disruptions occur, the pull model or event store may be preferable; and if strong consistency and transactionality are necessary, the push model or broker may be a better option. Conversely, if you can accept some delay and eventual consistency with compensating actions, the pull model or event store may be more appropriate.

5 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?