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

Question

Goal: Determine how the interaction between NgRx Effects and Angular's HttpClient influences request‑latency when several Store actions are dispatched concurrently.

Constraints: NgRx Effects process actions synchronously; the choice of mergeMap versus concatMap changes request ordering and concurrency, while the Store runs reducers on the microtask queue and selectors may recompute rapidly. It is unclear which factor dominates latency under realistic load, and whether version‑specific operator internals (pre‑NgRx 12) alter the outcome.

Specific questions:

Does using mergeMap in an Effect reduce observed latency compared to concatMap when N concurrent actions trigger HTTP calls?
How does the synchronous execution of reducers on the microtask queue affect latency as the number of dispatched actions grows?
Do selector memoization stale‑state recomputations add measurable overhead during bursts of actions?

Tasadduq Burney · Answer

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

Open DevTools Network tab → filter XHR/fetch.
  Dispatch two identical actions rapidly (e.g., via component button double-click).
  Observe: two separate requests = no deduplication; one request = caching/interceptor active.
  Temporarily swap mergeMap → concatMap in the effect; reload and repeat. If latency becomes predictable/sequential, the bottleneck was concurrency contention.
  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.

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

1 answer

0 question comments

Direct Answers

Confirmed Facts vs. Likely Explanations

Minimal Verification Steps

One Diagnostic Detail That Changes the Recommendation

Your perspective belongs here.

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