Push pull techs

short polling

The client (consumer) sends a request every N seconds

pros
- it's easy to understand
- it's easy to implement
cons
- difficult to define a proper value for the interval
- increased number of empty responses (or not new data)
- this ends up, to consume resources on the server (broker side)
resources that used for every client (consumer) request
- connection management
- authentication/authorization
- rate limiting
- TLS termination
- request validation
- ...

long polling

if there are messages to the queue server (broker) sends the message to the client immediately.
A connection is kept open for a specified interval (this is specified from the client).

pros
- less resources consumption
- reduces the number of empty responses
cons
- not good when you client expects immediate response from the server (broker)

web sockets

upgrade header included/required (both client and server)!
pros
- bi-directional
- re-uses the initial TCP connection
- fast

server-sent events

You can imagine it as a server job runs periodically that sends messages every time a message is available (similar to long polling).

use cases
- live feed
- client progress
- logging
pros
- simplicity
- compatible HTTP and HTTP/2 (this is not possible with web sockets)
- lightweight (no extra headers)
- Firewall friendly
cons
- proxying is tricky
- one way direction
- open connection for a long time
- stateful, difficult to scale horizontally