firehose of data not many subscribers of same message (bc reads would get too heavy)
- Azure Event Bus
- subscribers: low amount amount of subscribers (consumer groups) per message (max 20ish)
- think of subscribers as
- throughput: huge amount of messages (millions per second)
- resilience: not built in, since subscribers own the management of pointer on the stream
- ordering: not maintained, since subscribers own the management of pointer on the stream
- use case:
- uber - stream driver location (worker apps consume and store to redis shards)
- subscribers: low amount amount of subscribers (consumer groups) per message (max 20ish)