The user is on the subway with no signal but keeps working in the app — creating notes, sending messages. These actions pile up in a queue. When the network returns, we send them all, in the same order.
The problem it solves
Order matters: "create product" must go out before "update product". Just send the accumulated actions in parallel and the backend gets them out of order and may fall apart. An imperative array-queue is mutated from different handlers (online/action), easy to get out of sync.
Operators and why they matter
merge — combines two streams: new actions and reconnect events.
scan — holds the queue state as a pure function (no array mutations).
filter — on flush, pass on only a non-empty queue.
concatMap — send the actions STRICTLY in sequence. Order is preserved.
Gotchas
mergeMap instead of concatMap — parallel sending, order broken.
switchMap — the next reconnect cancels the flush, and some actions never go out.
Decide up front: what to do when one action errors? Stop the queue? Move it to the back for retry? Drop and log it? Without a decision — uncontrolled behavior.
What you get
Offline actions aren't lost and reach the backend in the right order after reconnect.