Introduction

An RxJS Observable does not automatically mean “asynchronous.” It means “a producer that pushes values to a subscriber.” That producer may emit later, or it may emit immediately during the subscribe() call.

So if an observable “returns data immediately,” that is usually because its source is synchronous, not because RxJS is breaking async behavior.

Observables Can Be Synchronous

A simple example is of().

1import { of } from 'rxjs';
2
3console.log('before subscribe');
4
5of(1, 2, 3).subscribe(value => {
6  console.log('value:', value);
7});
8
9console.log('after subscribe');

Output:

1before subscribe
2value: 1
3value: 2
4value: 3
5after subscribe

The values arrive immediately because of() emits synchronously by default.

Subscription Runs the Producer

Observables are lazy. Nothing happens until you subscribe. At subscription time, RxJS executes the observable’s producer logic.

If that producer pulls from an in-memory source, it can emit right away.

1import { Observable } from 'rxjs';
2
3const obs = new Observable<number>(subscriber => {
4  subscriber.next(42);
5  subscriber.complete();
6});
7
8obs.subscribe(x => console.log(x));

Again, this is synchronous because there is no timer, network request, or scheduler involved.

Truly Asynchronous Sources Behave Differently

Compare that with interval() or a Promise-based source.

1import { interval } from 'rxjs';
2
3console.log('before');
4interval(1000).subscribe(x => console.log(x));
5console.log('after');

Here, after prints before any emitted values because the source itself is time-based and asynchronous.

Why This Confuses People

Developers often learn observables in the context of HTTP requests, events, timers, or websockets. Those are asynchronous sources, so it is easy to infer the wrong rule: “observables are async.”

The better rule is:

• an observable describes a stream
• the source decides whether emissions are sync or async

RxJS supports both.

You Can Force Async Scheduling

If you want a synchronous source to emit asynchronously, use scheduling operators or a scheduler-aware creation pattern.

1import { of, asyncScheduler } from 'rxjs';
2import { observeOn } from 'rxjs/operators';
3
4console.log('before subscribe');
5
6of(1, 2, 3)
7  .pipe(observeOn(asyncScheduler))
8  .subscribe(value => console.log('value:', value));
9
10console.log('after subscribe');

Now the values are scheduled asynchronously rather than being pushed inline.

Practical Implication for Application Code

This matters when:

• you expect state to change after the current call stack finishes
• you write tests around emission timing
• you mix observables with promises or UI lifecycle code
• you assume subscribe() itself never triggers immediate side effects

If the source is synchronous, your handler can run before the next line after subscribe() executes.

That is why side effects inside subscribe() should be treated carefully. A synchronous observable can mutate component state, fire logging, or trigger nested subscriptions immediately, which changes how you reason about execution order.

This is also why BehaviorSubject often feels “immediate”: it synchronously emits its current cached value to new subscribers unless you deliberately defer the stream.

Common Pitfalls

• Assuming every observable behaves like an HTTP request or timer.
• Writing code that expects subscribe() handlers to run later when the source emits synchronously.
• Confusing “lazy” with “asynchronous.” An observable can be lazy and still synchronous once subscribed.
• Forgetting that operators may preserve the source timing unless you explicitly add scheduling.
• Testing timing-sensitive code without checking whether the source is sync or async.

Summary

• RxJS observables are not inherently asynchronous.
• A synchronous source such as of() can emit immediately during subscribe().
• The timing depends on the producer and any schedulers or operators involved.
• Use async scheduling when you need deferred emission behavior.
• Think of observables as a stream abstraction, not as a synonym for async execution.