Choosing a Communication Pattern

In a pull model, the client owns the schedule — it asks repeatedly and accepts that most answers will be "nothing changed." In a push model, the server owns the timing — it calls the moment something happens, and the client's job is just to be reachable.

Neither is strictly better. Pull is simple and works behind any firewall; push is efficient but demands infrastructure on the receiving end. The right choice depends on who can be reached, and how fresh the data needs to be.

Each pattern trades implementation simplicity for freshness and efficiency. The right one depends on whether the receiver can accept inbound connections, how stale the data is allowed to get, and how much infrastructure you're willing to run.

Five patterns, and the whole comparison comes down to who opens the connection, and how long it stays open. Everything else — freshness, cost, what infrastructure you need — falls out of those two answers.

A webhook call is a single, best-effort HTTP request from someone else's server to yours. If your endpoint is down, slow, or returns a non-2xx status, that event can be retried, delayed, or — eventually — dropped, depending on the sender's retry policy.

Because retries happen, the same event can also arrive more than once. Any receiver that isn't built to handle both of those failure modes will eventually miss an event or double-process one.