Memory leaks happen when subscriptions aren't torn down — use takeUntil or takeUntilDestroyed
Plain-English First
Imagine you subscribe to a newspaper. You don't get every paper ever printed — you only get new ones from the day you subscribed. That's an Observable: a source that delivers values over time, only to whoever is actively listening. A Promise is like ordering one pizza — it arrives once and it's done. An Observable is like a pizza conveyor belt at a restaurant — it keeps sending slices as long as you're sitting at the table, and the moment you leave (unsubscribe), the slices stop coming to you.
Every modern JavaScript app — whether it's an Angular dashboard, a React data-fetching layer, or a Node.js event pipeline — eventually runs into the same problem: asynchronous data that arrives in bursts, needs to be transformed, combined with other streams, and cancelled gracefully. setTimeout and Promises handle one-shot async well, but they fall apart the moment you need to debounce a search box, retry a failing API call with exponential backoff, or merge a WebSocket stream with an HTTP response. RxJS was built exactly for that world.
RxJS (Reactive Extensions for JavaScript) brings the Observer pattern, the Iterator pattern, and functional programming together into one composable API. At its core, an Observable is a lazy, cancellable, composable data pipeline. Unlike a Promise, it can emit multiple values over time, it doesn't start executing until something subscribes to it, and it can be torn down mid-flight — which is the key to avoiding memory leaks in dynamic UIs.
By the end of this article you'll understand how Observables work under the hood, why cold vs hot matters in production, how the most important operators actually compose, how multicasting prevents redundant network calls, and exactly which mistakes ship bugs to production. You'll also walk away with interview-ready answers that go beyond surface-level definitions.
How Observables Work Internally — Not Just What They Are
Most tutorials treat Observable as a black box. Let's crack it open. At its simplest, an Observable is a function that accepts an Observer (an object with next, error, and complete callbacks) and returns a teardown function. That's the entire contract. When you call subscribe(), RxJS invokes that producer function and wires up the observer. Nothing happens before that call — that's what 'lazy' means.
This is fundamentally different from a Promise, which starts its executor synchronously the moment you call new Promise(). An Observable defers all work until subscription time, which means you can pass an Observable around, compose it with operators, and store it in a variable without triggering any side effects. That referential transparency is what makes Observables safe to compose.
The teardown function returned by the producer (or set via subscriber.add()) is called when you unsubscribe, or when the Observable completes or errors. This is the foundation of RxJS's memory-safety story — every resource (timers, event listeners, WebSocket connections) must be cleaned up in that teardown. If your custom Observable doesn't return a teardown, you've created a leak.
ObservableInternals.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
import { Observable } from'rxjs';
// Creating an Observable from scratch reveals its internals.// The function we pass IS the producer — it runs only on subscribe().const intervalObservable = newObservable((subscriber) => {
let tickCount = 0;
console.log('[Producer] Observable execution started');
// setInterval is the resource we must clean up.const intervalId = setInterval(() => {
tickCount++;
console.log(`[Producer] Emitting tick #${tickCount}`);
subscriber.next(tickCount); // Push value to observerif (tickCount === 3) {
clearInterval(intervalId); // Stop the interval ourselves
subscriber.complete(); // Signal no more values
}
}, 500);
// Return teardown logic — called if consumer unsubscribes earlyreturn () => {
console.log('[Teardown] Interval cleared — no leak');
clearInterval(intervalId);
};
});
console.log('[Main] Observable defined — nothing running yet');
const subscription = intervalObservable.subscribe({
next: (tick) => console.log(`[Observer] Received: ${tick}`),
error: (err) => console.error(`[Observer] Error: ${err}`),
complete: () => console.log('[Observer] Stream complete'),
});
// Uncomment to see teardown fire before tick #3:// setTimeout(() => subscription.unsubscribe(), 800);
Output
[Main] Observable defined — nothing running yet
[Producer] Observable execution started
[Producer] Emitting tick #1
[Observer] Received: 1
[Producer] Emitting tick #2
[Observer] Received: 2
[Producer] Emitting tick #3
[Observer] Received: 3
[Teardown] Interval cleared — no leak
[Observer] Stream complete
Why Lazy Evaluation Matters:
Because Observables don't execute until subscribed, you can build a retry-with-backoff pipeline, store it in a service property, and hand it to three different components — each component gets its own independent execution with its own retry counter. This is the cold Observable contract and it's what makes RxJS pipelines reusable without hidden shared state.
Production Insight
Forgetting to return a teardown function from a custom Observable is the #1 cause of resource leaks in internal tooling.
Always test that unsubscribing stops all side effects — use console.log in the teardown to verify.
Rule: if your Observable allocates resources (timers, listeners, sockets), the teardown function must release them.
Key Takeaway
An Observable is just a function with a teardown contract.
Nothing runs until subscribe() is called.
The teardown function is your only guarantee against leaks — never omit it.
Cold vs Hot Observables — The Distinction That Ships Bugs
This is the single most misunderstood concept in RxJS and the root cause of both duplicate API calls and missed WebSocket messages. Understanding it deeply separates senior RxJS engineers from everyone else.
A cold Observable creates its producer fresh for each subscriber. Each subscriber gets the complete sequence from the beginning, with its own independent execution context. The interval example above is cold — two subscribers would each get their own timer. fromFetch(), ajax(), and interval() are cold by default.
A hot Observable shares a single producer among all subscribers. Subscribers only receive values emitted after they subscribe — like a live concert stream. fromEvent() (wrapping a DOM event) is hot because there's one event listener on the element, not one per subscriber.
The danger zone is HTTP requests: if you build a search-as-you-type feature using a cold ajax() Observable and render it in two places, each render triggers a separate HTTP request. The fix is multicasting — turning a cold Observable hot so all subscribers share one execution. shareReplay(1) is the production workaround most Angular devs reach for, but it has its own subtleties around refCounting and memory.
ColdVsHotMulticast.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
import { Observable, Subject, interval } from'rxjs';
import { share, shareReplay, take } from'rxjs/operators';
// ─── COLD Observable demonstration ─────────────────────────────────────────const coldTimer$ = newObservable((subscriber) => {
// Each subscriber gets its own counter starting from 0let count = 0;
const id = setInterval(() => subscriber.next(count++), 300);
return () => clearInterval(id);
}).pipe(take(3));
console.log('--- COLD: two subscribers get independent streams ---');
coldTimer$.subscribe(v => console.log(`ColdSubscriber A: ${v}`));
setTimeout(() => {
coldTimer$.subscribe(v => console.log(`ColdSubscriber B: ${v}`));
}, 400); // B starts 400ms late — still gets 0, 1, 2 from its own producer// ─── HOT Observable via Subject ────────────────────────────────────────────// A Subject is both an Observable and an Observer — it's the canonical hot source.const liveScore$ = newSubject();
setTimeout(() => {
console.log('\n--- HOT: Subject shares one stream ---');
liveScore$.subscribe(score => console.log(`Fan A sees: ${score}`));
// Emit the first goal — both fans see it (if subscribed at that moment)
liveScore$.next('Goal! 1-0');
// Fan B subscribes after the first goal — they MISS it
liveScore$.subscribe(score => console.log(`Fan B sees: ${score}`));
liveScore$.next('Goal! 2-0'); // Only this one is seen by Fan B
liveScore$.complete();
}, 1200);
// ─── shareReplay: solve the cold HTTP + multiple subscriber problem ─────────// Simulating an HTTP call that should only fire ONCEconst expensiveApiCall$ = newObservable((subscriber) => {
console.log('\n[HTTP] Making API call — this should only appear ONCE');
setTimeout(() => {
subscriber.next({ user: 'Alice', role: 'admin' });
subscriber.complete();
}, 100);
}).pipe(
shareReplay(1) // Replay last 1 emission to late subscribers; share the single HTTP call
);
setTimeout(() => {
// Two components subscribe — only one HTTP call fires
expensiveApiCall$.subscribe(data => console.log('[Component Header] Got:', data));
expensiveApiCall$.subscribe(data => console.log('[Component Sidebar] Got:', data));
}, 2400);
Output
--- COLD: two subscribers get independent streams ---
Cold Subscriber A: 0
Cold Subscriber A: 1
Cold Subscriber B: 0
Cold Subscriber A: 2
Cold Subscriber B: 1
Cold Subscriber B: 2
--- HOT: Subject shares one stream ---
Fan A sees: Goal! 1-0
Fan A sees: Goal! 2-0
Fan B sees: Goal! 2-0
[HTTP] Making API call — this should only appear ONCE
shareReplay(1) without { refCount: true } keeps the inner subscription alive even after all consumers unsubscribe. In Angular services loaded into long-lived modules this leaks memory across navigation. Use shareReplay({ bufferSize: 1, refCount: true }) in production, which tears down the shared subscription when the last subscriber leaves.
Production Insight
Confusing cold and hot is the root cause of duplicate HTTP calls and missed WebSocket events.
Always identify your source type before choosing the multicasting strategy.
Rule: cold sources need shareReplay to become hot; hot sources need no multicasting.
Key Takeaway
Cold = each subscriber gets its own execution.
Hot = all subscribers share one execution.
shareReplay with refCount: true bridges the gap without leaking.
Operator Internals and Composition — map, switchMap, mergeMap, exhaustMap Compared
Operators are pure functions that take an Observable and return a new Observable. They don't mutate the source — each operator wraps the previous one in a new layer, forming a pipeline. Under the hood, pipe() is just function composition: pipe(opA, opB, opC) is equivalent to opC(opB(opA(source))).
The higher-order mapping operators — switchMap, mergeMap, concatMap, exhaustMap — are where most production bugs live. They all accept a function that maps each emitted value to an inner Observable. The difference is what they do with overlapping inner subscriptions.
switchMap cancels the previous inner Observable when a new outer value arrives. This is perfect for autocomplete — you only care about the response for the latest keystroke. mergeMap subscribes to every inner Observable concurrently, which is useful for parallel requests but can overwhelm a server. concatMap queues them, processing one at a time in order. exhaustMap ignores new outer values while an inner Observable is still active — ideal for a login button that shouldn't fire twice.
Choosing the wrong one causes race conditions (mergeMap for search), dropped requests (exhaustMap for pagination), or stalled queues (concatMap when order doesn't matter but throughput does).
[switchMap] New term "slow" — cancelling previous inner subscription
[switchMap] New term "fast" — cancelling previous inner subscription
[API] Response ready for: "fast"
[UI] Showing: Results for: "fast"
=== exhaustMap (login button) ===
[Auth] Sending login request...
[Auth] Result: Login success
=== concatMap (ordered file uploads) ===
[Upload] Starting: file-1.jpg
[Upload] Done: file-1.jpg uploaded
[Upload] Starting: file-2.jpg
[Upload] Done: file-2.jpg uploaded
[Upload] Starting: file-3.jpg
[Upload] Done: file-3.jpg uploaded
Decision Rule for Higher-Order Operators:
Ask yourself: 'What should happen if a new event arrives while the previous one is still processing?' Cancel old → switchMap. Stack them → mergeMap. Queue them → concatMap. Ignore new → exhaustMap. Tattoo this on your brain before any RxJS interview.
Production Insight
MergeMap for autocomplete fires multiple HTTP calls and renders stale data — a classic production bug.
ConcatMap for parallel requests blocks the entire stream — throughput drops to 1 at a time.
Rule: the operator choice is a contract about concurrency — pick the one that matches your UI's intent.
Ask: 'What should happen if a new event arrives while previous is processing?'
The answer dictates the operator — and prevents race conditions.
Higher-Order Operator Decision Tree
IfSingle service, no dependencies
→
UseUse docker run — Compose adds no value
IfMultiple services that must talk to each other
→
UseUse Compose — it handles custom networks and service names
IfNeed to scale one service independently
→
UseUse Docker Compose with --scale or a swarm/compose file with replicas
Production Patterns — Error Handling, Retry and Memory Management
Error handling in RxJS is a trap for the unprepared. When an Observable errors, it terminates — no more values, no recovery. That means if you have a WebSocket stream and it throws, your UI goes silent. The answer is catchError, which intercepts an error and must return a new Observable (including EMPTY to silently swallow it, or throwError to re-throw).
retryWhen and its modern replacement retry({ delay, count }) let you implement exponential backoff — critical for flaky API endpoints. But retry resubscribes to the entire source Observable, which for cold Observables means a fresh HTTP call — exactly what you want. For hot sources, retry can cause confusing behaviour because the source doesn't reset.
For memory management in SPAs, the takeUntilDestroyed() operator (Angular 16+) or the classic takeUntil(destroy$) pattern ensures subscriptions are torn down when a component unmounts. In React with RxJS, cleaning up in useEffect's return function is the equivalent. Forgetting this in a long-lived app with many navigations leads to dozens of stale subscriptions running in the background, causing ghost updates to unmounted components and measurable memory growth you'll only catch in a production heap snapshot.
ProductionErrorHandling.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
import { throwError, of, Subject, timer } from'rxjs';
import {
catchError,
retry,
switchMap,
takeUntil,
finalize,
tap,
mergeMap,
delayWhen
} from'rxjs/operators';
// ─── Exponential backoff retry ───────────────────────────────────────────────let attemptCount = 0;
const unreliableApi$ = newSubject().pipe(
// This pattern is used to kick off an Observable manually
);
// Simulates a flaky fetch that succeeds on the 3rd attemptconst fetchWithRetry$ = new (require('rxjs').Observable)((subscriber) => {
attemptCount++;
console.log(`[HTTP] Attempt #${attemptCount}`);
if (attemptCount < 3) {
subscriber.error(newError(`Network timeout on attempt ${attemptCount}`));
} else {
subscriber.next({ data: 'User profile fetched successfully' });
subscriber.complete();
}
}).pipe(
// retry with exponential backoff — delay doubles each time, max 3 retriesretry({
count: 3,
delay: (error, retryIndex) => {
const backoffMs = Math.pow(2, retryIndex) * 100; // 200ms, 400ms, 800ms
console.log(`[Retry] Attempt ${retryIndex} after ${backoffMs}ms — Reason: ${error.message}`);
returntimer(backoffMs);
},
}),
catchError((finalError) => {
// Only runs if all retries are exhausted
console.error(`[Error] Giving up after all retries: ${finalError.message}`);
// Return a fallback value so the stream recovers instead of dyingreturnof({ data: 'Cached fallback data', fromCache: true });
}),
finalize(() => console.log('[Cleanup] HTTP stream finalized — run cleanup here'))
);
fetchWithRetry$.subscribe({
next: (result) => console.log('[UI] Displaying:', result),
complete: () => console.log('[UI] Done'),
});
// ─── takeUntil pattern — prevents memory leaks ──────────────────────────────setTimeout(() => {
console.log('\n--- takeUntil (component lifecycle) ---');
// In a real app this would be a component's ngOnDestroy Subject or React useEffect cleanupconst componentDestroyed$ = newSubject();
const liveDataStream$ = new (require('rxjs').interval)(200).pipe(
tap(tick => console.log(`[Stream] Tick ${tick} — component still alive`)),
takeUntil(componentDestroyed$) // auto-unsubscribes when destroy$ emits
);
liveDataStream$.subscribe({
next: (tick) => console.log(`[Component] Rendered tick: ${tick}`),
complete: () => console.log('[Component] Subscription cleaned up — no leak'),
});
// Simulate component unmount after 500mssetTimeout(() => {
console.log('[Component] Unmounting...');
componentDestroyed$.next(true);
componentDestroyed$.complete();
}, 500);
}, 1500);
Output
[HTTP] Attempt #1
[Retry] Attempt 1 after 200ms — Reason: Network timeout on attempt 1
[HTTP] Attempt #2
[Retry] Attempt 2 after 400ms — Reason: Network timeout on attempt 2
[HTTP] Attempt #3
[Cleanup] HTTP stream finalized — run cleanup here
Interview Gold — catchError Must Return an Observable:
A classic mistake is returning a plain value from catchError (e.g. return null). This throws a runtime error because RxJS expects an ObservableInput from catchError's callback. Always return of(fallbackValue), EMPTY, or throwError(() => new Error(...)) — never a raw value.
Production Insight
An unhandled error in a WebSocket stream kills the entire connection silently — users see stale data.
Retry on a hot source attempts to resubscribe to a source that doesn't reset — confusing results.
Rule: always pair long-lived subscriptions with takeUntil, and use catchError at the boundary of every network stream.
Key Takeaway
Errors kill Observables forever.
catchError must return an Observable, not a value.
retry only works correctly on cold sources — understand the source type.
When you need to share a single execution among multiple subscribers, you need multicasting. The core mechanism is Subject — a type that is both an Observable and an Observer. You push values into it via next(), and all subscribed observers receive them.
BehaviorSubject extends Subject: it remembers the last emitted value and replays it to new subscribers immediately. This makes it perfect for 'current user' state — when a component initializes, it gets the current user without waiting for a new emission.
ReplaySubject replays a configurable number of past emissions (or all). Use it for caching transient data like search results that you want to show for a few seconds after navigation.
AsyncSubject replays only the last value after the source completes. It's rarely used but perfect for loading a resource that you know will eventually complete.
The key to multicasting correctly is understanding that the Subject is the 'bridge' from cold to hot. You can create a Subject, subscribe your source Observable to it, and then expose the Subject as the hot observable. Operators like share, shareReplay, and publish do this internally. shareReplay is the most common production choice because it also caches the last value for late subscribers.
MulticastingSubjects.jsJAVASCRIPT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
import { Subject, BehaviorSubject, ReplaySubject, AsyncSubject, of, timer } from'rxjs';
import { delay, tap } from'rxjs/operators';
// ─── Subject – basic hot source ───────────────────────────────────────────────const subject$ = newSubject();
subject$.subscribe(v => console.log(`Subject A: ${v}`));
subject$.next('first'); // A gets itconst subB = subject$.subscribe(v => console.log(`Subject B: ${v}`));
subject$.next('second'); // A and B get it
subject$.next('third'); // A and B get it// ─── BehaviorSubject – remembers last value ───────────────────────────────────
console.log('\n--- BehaviorSubject ---');
const initial = { user: 'guest' };
const currentUser$ = newBehaviorSubject(initial);
// Late subscriber gets the last value immediately
currentUser$.subscribe(user => console.log(`Sub1: ${user.user}`));
currentUser$.next({ user: 'Alice' });
currentUser$.next({ user: 'Bob' });
// This subscriber will receive Bob immediately upon subscription
currentUser$.subscribe(user => console.log(`Sub2 (late): ${user.user}`));
// ─── ReplaySubject – replays past N emissions ─────────────────────────────────
console.log('\n--- ReplaySubject (buffer 2) ---');
const replay$ = new ReplaySubject(2); // replay last 2 values
replay$.next('a');
replay$.next('b');
replay$.next('c');
// Subscriber gets 'b' and 'c' (the 2 buffered)
replay$.subscribe(v => console.log(`Replay A (late): ${v}`));
replay$.next('d');
// ─── AsyncSubject – emits last value only on complete ─────────────────────────
console.log('\n--- AsyncSubject ---');
const asyncSubject$ = newAsyncSubject();
asyncSubject$.subscribe(v => console.log(`AsyncSub1: ${v}`));
asyncSubject$.next('first'); // ignored
asyncSubject$.next('last'); // this is the value kept
asyncSubject$.complete(); // now 'last' is emitted to all subscribers// Late subscriber also gets 'last'
asyncSubject$.subscribe(v => console.log(`AsyncSub2 (late): ${v}`));
Output
Subject A: first
Subject A: second
Subject B: second
Subject A: third
Subject B: third
--- BehaviorSubject ---
Sub1: guest
Sub1: Alice
Sub1: Bob
Sub2 (late): Bob
--- ReplaySubject (buffer 2) ---
Replay A (late): b
Replay A (late): c
Replay A (late): d
--- AsyncSubject ---
Async Sub1: last
Async Sub2 (late): last
Thinking in Subjects
Subject: no memory, only live listeners — like a live radio show
BehaviorSubject: remembers the last value — like a whiteboard that shows the current state
ReplaySubject: remembers a configurable history — like a DVR that replays the last N minutes
AsyncSubject: waits until the end to share the final value — like a race result announced after the match
Production Insight
Using a plain Subject when you need BehaviorSubject means late subscribers wait forever — a common bug in dynamic forms.
ReplaySubject without a buffer limit can keep an unbounded history — memory leak if the source emits frequently.
Rule: choose the Subject variant that matches the subscriber timing requirements — BehaviorSubject for current state, ReplaySubject for short-term caching, and AsyncSubject for one-shot loading operations.
Key Takeaway
Subject = live broadcast.
BehaviorSubject = remembers last value.
ReplaySubject = remembers history.
AsyncSubject = remembers final value after complete.
Use the right Subject variant — it prevents subscriber starvation and memory bloat.
● Production incidentPOST-MORTEMseverity: high
Memory Leak from shareReplay Without refCount in Angular Service
Symptom
Angular app becomes progressively slower after each navigation. Chrome DevTools heap snapshot shows thousands of detached DOM nodes and increasing retained size from RxJS subscriptions. Garbage collection cycles take longer each time.
Assumption
The team assumed shareReplay(1) would automatically clean up when the last component unsubscribes, based on tutorials showing shareReplay as the magic fix for duplicate HTTP calls.
Root cause
shareReplay without { refCount: true } creates an infinite internal subscriber. Even after all external subscribers unsubscribe, the shared subscription to the source Observable remains alive because the ReplaySubject caches the value for potential late subscribers. In a long-lived module, this accumulates every time the observable is accessed — each new call to shareReplay creates a new internal subscription that never dies.
Fix
Replace shareReplay(1) with shareReplay({ bufferSize: 1, refCount: true }). The refCount: true option tears down the shared subscription when the last external subscriber leaves (trimming from 1 to 0). For additional safety in Angular, pair with takeUntilDestroyed() in the service itself.
Key lesson
Always use refCount: true with shareReplay in long-lived environments
Test with simulated navigation cycles and check heap snapshots
Treat shareReplay as an optimization, not a free lunch — understand when it keeps state alive
Production debug guideTrack down ghost subscriptions that keep components alive and bloat memory4 entries
Symptom · 01
Component updates (e.g., Angular change detection) continue after component is destroyed
→
Fix
Check for missing unsubscribe in ngOnDestroy or useEffect cleanup. Add a console.log('subscribing') inside the observable's next handler to verify if it's still firing after destroy.
Symptom · 02
Heap snapshot shows large retained size from RxJS objects (Observable, Subject, Subscription)
→
Fix
Use Chrome DevTools → Memory → Take heap snapshot. Filter by 'Observable' or 'Subscription'. Look for retained objects without a reference from a live component. Use rxjs-spy or custom tap operator to log subscriber counts.
Symptom · 03
API calls continue firing after user navigates away
→
Fix
switchMap cancels previous inner subscription; mergeMap does not. Verify operator choice. Add a takeUntil(destroy$) that emits true in the component clean-up hook.
Symptom · 04
shareReplay stream fires execution more than once
→
Fix
Check subscriber count. Use shareReplay({ bufferSize: 1, refCount: true }). Verify the source Observable is not recreated on each access (e.g., avoid wrapping in a function that returns a new pipe each call).
★ Quick RxJS Memory & Subscription DebuggingCommon symptoms and immediate actions for production RxJS issues.
Component continues updating after unmount−
Immediate action
Check component lifecycle hooks for unsubscribe logic
Commands
Add `tap(console.log)` in observable pipeline to trace emissions
Use rxjs-spy: `import { spy } from 'rxjs-spy'; window.rxjsSpy = spy.create();`
Fix now
Wrap subscription with takeUntil(destroy$) where destroy$ emits in destroy hook
HTTP request fires multiple times for same data+
Immediate action
Check if observable is cold and has multiple subscribers
Commands
Add `shareReplay({bufferSize:1, refCount:true})` after the HTTP source
Verify the observable is defined as a property, not created inside a getter
Fix now
Replace this.http.get(url) in each subscriber with a shared observable stored in service
Subscriber only receives some events (race condition)+
Switch to appropriate higher-order operator based on requirement
Higher-Order Operator Comparison
Behaviour
switchMap
mergeMap
concatMap
exhaustMap
Concurrent inner subscriptions
1 (kills previous)
Unlimited
1 (queued)
1 (blocks new)
Cancels in-flight inner
Yes
No
No
No
Ordering of results
Latest only
Race order
Source order guaranteed
Source order (only first while idle)
Best use case
Autocomplete / latest-value-wins
Parallel API calls
Sequential uploads / ordered mutations
Login / payment button (no double submit)
Risk if misused
Race conditions if used for mutations
Server overwhelm / out-of-order responses
Backpressure / UI stalls if queue grows
Silent dropped events if UX isn't clear
Key takeaways
1
An Observable is a lazy function
it does nothing until subscribe() is called. Returning a teardown function from the producer is what separates memory-safe from leaky custom Observables.
2
Cold Observables create a new execution per subscriber (HTTP calls, timers). Hot Observables share one execution (DOM events, WebSockets). Confusing the two causes duplicate network requests or missed events
shareReplay({ bufferSize: 1, refCount: true }) is the production bridge.
3
switchMap, mergeMap, concatMap and exhaustMap differ only in what they do with overlapping inner subscriptions. Getting this wrong causes race conditions, double form submissions, or stalled UIs
always ask 'what if a new event fires while the previous inner Observable is still alive?'
4
When an Observable errors, it terminates permanently. catchError must return an ObservableInput (not a raw value) to recover the stream. Combine with retry({ delay, count }) for exponential backoff on flaky endpoints, and always pair long-lived subscriptions with takeUntil to avoid memory leaks in SPAs.
5
Multicasting via Subject, BehaviorSubject, or shareReplay is essential for sharing state across subscribers. Choose BehaviorSubject for current state, ReplaySubject for short-term caching, and never forget refCount with shareReplay.
Common mistakes to avoid
3 patterns
×
Using catchError that returns a plain value instead of an Observable
Symptom
Your app throws 'You provided 'null' where a stream was expected' at runtime, and the entire observable chain breaks without recovery.
Fix
Always wrap the fallback in of(fallbackValue) or return EMPTY if you want to silently swallow the error.
×
Forgetting to unsubscribe in long-lived components (React/Angular)
Symptom
Memory grows over time, components throw 'Cannot setState on unmounted component' or Angular change detection errors after navigation. Heap snapshots show detached trees with RxJS subscription references.
Fix
Use the takeUntil pattern: create a destroy$ Subject that emits in ngOnDestroy (Angular) or useEffect cleanup (React), and pipe takeUntil(destroy$) on every long-lived subscription.
×
Using shareReplay without refCount: true in a service that lives as long as the app
Symptom
API calls continue firing even after all components that use the data are destroyed. Memory usage grows with each navigation cycle.
Fix
Always use shareReplay({ bufferSize: 1, refCount: true }) to ensure the shared subscription tears down when the subscriber count drops to zero.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What is the difference between a cold and a hot Observable, and how does...
Q02SENIOR
Explain the difference between switchMap, mergeMap, concatMap and exhaus...
Q03SENIOR
An Observable emits values, then errors. You add a catchError that retur...
Q01 of 03SENIOR
What is the difference between a cold and a hot Observable, and how does shareReplay convert one to the other? Can you describe a real scenario where mixing them up caused a bug?
ANSWER
A cold Observable creates a new producer per subscriber (e.g., fromFetch, interval). Each subscriber gets the entire sequence. A hot Observable shares one producer (e.g., fromEvent, Subject). shareReplay(1) wraps the source in a ReplaySubject, making it hot — late subscribers receive the last value from a shared execution, and new subscribers connect to the same producer. A real bug: an Angular service fetching user data used a cold ajax() in a method called from two components. Each component triggered a separate HTTP call, causing double billing on a paid API. The fix was to store the observable as a property with shareReplay(1) so both components share one execution.
Q02 of 03SENIOR
Explain the difference between switchMap, mergeMap, concatMap and exhaustMap. If you were building an autocomplete search and a form submission button, which would you use for each and why?
ANSWER
The four operators differ only in their handling of overlapping inner subscriptions. switchMap cancels the previous inner when a new outer value arrives — use it for autocomplete so the latest keystroke always wins. mergeMap subscribes concurrently to every inner — avoid it for search but use it for parallel API calls. concatMap queues inners in order — use it for ordered file uploads. exhaustMap ignores new outer while an inner is active — use it for a form submission button to prevent double submits. For autocomplete: switchMap. For submit button: exhaustMap.
Q03 of 03SENIOR
An Observable emits values, then errors. You add a catchError that returns of(fallback), but you notice the Observable never emits again after the error — even though you expected it to continue. Why does this happen and how do you fix it?
ANSWER
catchError intercepts the error and switches to a fallback Observable, but the original Observable is still completed (errors always complete the stream). The fallback becomes the new source, so further values from the original won't appear. If you need the original source to continue after an error, you need to retry with retry() or use a more advanced pattern like catchError inside a switchMap. For example, place catchError inside a nested observable: switchMap(() => source$.pipe(catchError(...))). This way the outer stream stays alive and can resubscribe.
01
What is the difference between a cold and a hot Observable, and how does shareReplay convert one to the other? Can you describe a real scenario where mixing them up caused a bug?
SENIOR
02
Explain the difference between switchMap, mergeMap, concatMap and exhaustMap. If you were building an autocomplete search and a form submission button, which would you use for each and why?
SENIOR
03
An Observable emits values, then errors. You add a catchError that returns of(fallback), but you notice the Observable never emits again after the error — even though you expected it to continue. Why does this happen and how do you fix it?
SENIOR
FAQ · 4 QUESTIONS
Frequently Asked Questions
01
What is the difference between an Observable and a Promise in JavaScript?
A Promise is eager (starts executing immediately), can only emit one value, and cannot be cancelled. An Observable is lazy (executes only on subscribe), can emit zero to infinite values over time, and supports cancellation via unsubscribe(). Observables are also composable — you can pipe operators over them before any data flows.
Was this helpful?
02
When should I use a Subject instead of a plain Observable?
Use a Subject when you need to push values imperatively into a stream — for example, triggering a stream from a button click handler or a Redux-style action dispatcher. A plain Observable is better when the source is declarative and self-contained (e.g. wrapping an HTTP call). BehaviorSubject is the go-to when late subscribers need the last emitted value immediately on subscription, like a current-user state store.
Was this helpful?
03
Why does RxJS have so many operators? Do I need to learn them all?
RxJS has ~100+ operators because async data has genuinely complex needs — combining streams, buffering, throttling, retrying, multicasting. In production you'll reach for about 15-20 operators 90% of the time: map, filter, tap, switchMap, mergeMap, concatMap, exhaustMap, catchError, retry, takeUntil, debounceTime, distinctUntilChanged, combineLatest, forkJoin, and shareReplay. Master those deeply rather than skimming all 100.
Was this helpful?
04
What is the purpose of shareReplay? Can it cause memory leaks?
shareReplay makes a cold Observable hot by sharing a single subscription and replaying the last N values to late subscribers. Without { refCount: true }, the shared subscription never ends, causing memory leaks in long-lived modules. Always use shareReplay({ bufferSize: 1, refCount: true }) unless you intentionally need a persistent cache.