Push versus pull architecture

01Who asks for the next item?

A shopper keeps an order-status screen open while the order changes from packed to shipped. Who starts the next exchange?

• Pull: the screen asks the order API for current status. It controls when to ask again and how much to fetch.
• Push: a delivery service contacts the registered screen or device when a change occurs. It needs a reachable channel or a way to save delivery work until the device returns.

One application can use both. The server may push “this order changed,” and the screen may then pull its saved current details. A worker may pull jobs from a queue even though another service pushes events into that queue. State the connection being discussed instead of labeling the entire system once.

Push can reduce the time before a screen learns of a change. Pull lets a slow or intermittent receiver control intake. Neither choice alone saves history or proves that the receiving application applied an update.

02Freshness and load come from the contract

Compare a screen's next update:

For polling, derive both cost and delay

1. Count active screens N and interval T seconds. Evenly spread polling creates about N/T requests/s.
2. State the timing assumption. If changes occur uniformly between polls, the average wait to the next poll is about T/2; interval-only worst waiting approaches T.
3. Add actual failures and processing. Those arithmetic waits are not hard network-inclusive freshness guarantees.
4. Vary polling times. Small timing variation, called jitter, prevents all devices asking at the same instant. It spreads work but does not reduce the total average requests.

For pushed updates, count recipients too. Sending one change to 100,000 subscribers can create 100,000 delivery attempts before retries. This multiplication is fanout.

03Worked example: order status

Assume 60,000 order screens poll every 30 seconds. They create 2,000 requests/s even if no orders change, with about 15 seconds mean interval wait under the uniform-timing assumption. Polling every two seconds raises the rate to 30,000/s.

Now follow a hybrid update. Order 42 is the saved order these screens display; its status has an increasing version number.

1. The order service saves shipped as version 8. If the product promises notification attempts, save pending notification work with the change so a crash cannot erase it.
2. The delivery service sends a small hint: order 42 now has version 8. This hint is not the only saved copy of the status.
3. A screen holding version 7 calls the authenticated order API. The screen includes version 8 from the hint as the minimum it needs. The API verifies that the caller may view this order, then returns version 8 or later. If its selected copy still has 7, it waits, chooses an updated source or returns a failure instead of presenting 7 as the requested update.
4. A repeated hint does not replace newer state. After applying version 8, the screen ignores a delayed version 7 hint and need not apply version 8 twice.
5. A sleeping device wakes. It fetches current status, or requests retained events after its saved position if every transition matters. Correctness does not require it to have received every live hint.
6. An active device occasionally checks its version anyway. This detects a missed signal even when the connection appeared healthy.

For a status display, keeping only the latest pending status may be enough. Do not apply that shortcut to payments or audit events where every transition triggers a separately required action. Also distinguish network receipt from the application saving or displaying the update; use an application acknowledgment when that milestone matters.

04Choose a delivery and recovery pair

Choose delivery together with recovery:

• Use pull when receivers run intermittently, need intake control or tolerate the calculated polling delay.
• Use push when sparse changes need prompt notice and its connection/delivery cost is justified.
• Use hints plus fetches when quick notice is useful but current saved state can repair missed notifications.
• Limit each receiver's buffer. One slow subscriber must not consume unlimited shared memory. Explain whether updates combine, wait, reject or resume from storage.
• Define acknowledgment and history retention. Reaching a device's network connection does not prove its application applied the update.

In an interview, name the sender, receiver, exact data and recovery source. Calculate active consumers, polling or update rate, recipients and payload. Then disconnect one receiver and slow another. Those traces determine the choice more accurately than calling push “real time” or pull “inefficient.”