NgRx Effects + Angular HttpClient: Latency behavior when multiple actions trigger concurrent requests

Direct Answers

1. mergeMap vs concatMap: mergeMap reduces observed latency only when the browser and server can actually run requests in parallel. Under HTTP/1.1 the ~6-connection limit serializes excess requests anyway, so mergeMap and concatMap often yield similar wall-clock times. Under HTTP/2 with a server that handles concurrent streams, mergeMap lets all N requests fly simultaneously while concatMap forces them into a sequential queue (latency ≈ N × single-request time).

2. Reducer microtask queue: Reducers run synchronously on the microtask queue. Each dispatched action completes its reducer pass before the next microtask runs. With dozens of actions the cumulative reducer time is measurable (typically <0.5 ms per action), but it rarely dominates latency compared to network round-trips.

3. Selector memoization overhead: NgRx createSelector memoizes by reference equality of input slices. During a burst, selectors recompute only when their specific slice changes. Unless you have expensive projections or many distinct slices mutating simultaneously, the overhead is sub-millisecond and not a primary latency driver.

Confirmed Facts vs. Likely Explanations

Confirmed (verifiable in DevTools)	Likely Explanation (depends on environment)
NgRx Effects default to mergeMap (unlimited inner subscriptions)	HTTP/2 multiplexing eliminates the 6-connection bottleneck
HttpClient creates a cold observable per dispatch — no auto-deduplication	Server-side rate limiting or prioritization caps real concurrency
Effect subscription overhead < 1 ms	Reducer microtask batching adds linear but tiny delay
concatMap serializes inner observables strictly	Selector recomputation cost scales with slice complexity

Minimal Verification Steps

1. Open DevTools Network tab → filter XHR/fetch.
2. Dispatch two identical actions rapidly (e.g., via component button double-click).
3. Observe: two separate requests = no deduplication; one request = caching/interceptor active.
4. Temporarily swap mergeMap → concatMap in the effect; reload and repeat. If latency becomes predictable/sequential, the bottleneck was concurrency contention.
5. Dispatch 10+ actions at once; count parallel requests in the waterfall. ≤6 simultaneous = HTTP/1.1 limit; >6 = HTTP/2 multiplexing.

One Diagnostic Detail That Changes the Recommendation

What protocol does the target endpoint use — HTTP/1.1 or HTTP/2? If HTTP/1.1, mergeMap gains little over concatMap because the browser connection limit serializes requests anyway. If HTTP/2, mergeMap (or mergeMap with concurrency: N) is the correct choice for latency reduction.