Observer Pattern in JavaScript Or TypeScript: Understanding Node.js EventEmitter

In this tutorial, we will learn about Observer Pattern in JavaScript Or TypeScript. Now let’s Imagine you are building a research paper ingestion platform. Whenever a new paper enters the system, several things need to happen. The paper should be added to a search index, users tracking its topic should receive email notifications, and an analytics service should record the event.

A straightforward implementation might look like this:

class PaperIngestionService {
  public ingestNewPaper(id: string, title: string): void {
    // Save the paper.

    // Update the search index.
    // Send email notifications.
    // Update analytics.
  }
}

Initially, this may seem reasonable. There is one place where a paper enters the system, so why not perform every related operation there?

The problem appears when the application grows. Suppose the team introduces a recommendation service, a moderation service, and a webhook integration. The ingestion service now needs to know about every downstream operation that should happen when a paper is added.

This creates tight coupling. Adding a new reaction to paper ingestion requires modifying the component responsible for ingesting papers, even if the new behavior has nothing to do with the ingestion process itself.

The deeper design question is:

How can one object announce that something has happened without needing to know every component that wants to react to it?

The Observer Pattern addresses this problem by allowing multiple interested objects to subscribe to another object’s events. When the publisher announces an event, its subscribers are notified.

This pattern is especially relevant to Node.js because event-driven programming is built into many of its APIs, including streams, networking, and the EventEmitter class.

2. Understanding the Observer Pattern

The Observer Pattern establishes a relationship between one object that produces events and multiple objects that react to them.

It has two main participants.

The publisher, sometimes called the subject, owns or controls the source of an event. It provides a way for interested parties to subscribe, unsubscribe, and receive notifications.

The subscribers, also called observers, register their interest and implement the behavior they want to perform when an event occurs.

For our research paper platform, the relationship looks like this:

                 New paper arrives                       |
                       v
              PaperIngestionService
                    Publisher
                       |
                 Paper ingested
                       |
             Notify all subscribers
               /         |         \
              v          v          v
        Search Index   Email      Analytics
          Updater      Service     Service

The publisher does not need to know how a search index works, how emails are delivered, or how analytics data is stored. It only needs to notify its subscribers.

Each subscriber owns its own reaction to the event.

This separation makes the system easier to extend. A new subscriber can be introduced without adding new business logic to the publisher, provided the subscription contract remains the same.

One important detail: the Observer Pattern does not inherently require threads, queues, or asynchronous processing. It describes a relationship between objects. Whether notification happens synchronously, asynchronously, or through a message broker depends on the implementation.

3. Define the Event and Subscriber Contracts

Before implementing the publisher, we need to define what information the event carries and what a subscriber must do.

For the paper ingestion example, we can define a typed event payload:

interface PaperIngestedEvent {
  id: string;
  title: string;
  timestamp: Date;
}

The event contains the paper’s identifier, title, and ingestion timestamp.

Next, define the subscriber interface:

interface ISubscriber {
  name: string;
  update(eventData: PaperIngestedEvent): void;
}

Every subscriber must have a name and an update() method that accepts the paper event.

The interface gives the publisher a consistent way to communicate with different subscribers. The publisher does not need to know the concrete type of the object receiving the notification. It only needs to know that the object implements ISubscriber.

We can also define the publisher’s contract:

interface IPublisher {
  subscribe(observer: ISubscriber): void;
  unsubscribe(observer: ISubscriber): void;
  notify(eventData: PaperIngestedEvent): void;
}

These methods define the basic lifecycle of the subscription relationship.

subscribe() registers an observer.

unsubscribe() removes an observer from future notifications.

notify() tells registered observers that an event has occurred.

Notice that PaperIngestedEvent is used instead of any. A typed event contract allows TypeScript to catch mistakes such as trying to access a nonexistent property or passing an unrelated payload to a subscriber.

The more event-driven a system becomes, the more valuable explicit event types are.

4. Implement the Observer Pattern Manually

Let us first implement the pattern without using Node.js’s built-in event system. This makes the mechanics visible.

class PaperIngestionService implements IPublisher {
  private subscribers: Set<ISubscriber> = new Set();

  public subscribe(observer: ISubscriber): void {
    this.subscribers.add(observer);

    console.log(
      `[System] ${observer.name} subscribed to paper events.`,
    );
  }

  public unsubscribe(observer: ISubscriber): void {
    this.subscribers.delete(observer);

    console.log(
      `[System] ${observer.name} unsubscribed.`,
    );
  }

  public notify(eventData: PaperIngestedEvent): void {
    console.log(
      `\n[Publisher] Broadcasting: ${eventData.title}`,
    );

    for (const subscriber of [...this.subscribers]) {
      subscriber.update(eventData);
    }
  }

  public ingestNewPaper(paperId: string, title: string): void {
    const event: PaperIngestedEvent = {
      id: paperId,
      title,
      timestamp: new Date(),
    };

    this.notify(event);
  }
}

There are a few deliberate design choices here.

First, subscribers is a Set rather than an array. A set prevents the exact same object reference from being registered multiple times, which avoids accidental duplicate notifications when a subscriber calls subscribe() repeatedly.

Second, unsubscribe() deletes the observer from the set. It does not need to rebuild an array manually.

Third, the notification loop iterates over a snapshot of the subscribers. This gives the current notification a stable list even if a subscriber changes the subscription list while handling the event.

Finally, ingestNewPaper() creates the event and delegates notification to notify(). This keeps the action that produces the event separate from the mechanism used to deliver it.

The overall flow is:

ingestNewPaper(id, title)
           |
           v
   Create typed event
           |
           v
       notify(event)
           |
           v
  Iterate over subscribers
       /      |      \
      v       v       v
   update   update   update

Now let’s implement the subscribers.

class SearchIndexUpdater implements ISubscriber {
  public name = "SearchIndexUpdater";

  public update(eventData: PaperIngestedEvent): void {
    console.log(
      `[${this.name}] Indexing "${eventData.title}"...`,
    );
  }
}

class AuthorTrackerEmailer implements ISubscriber {
  public name = "AuthorTrackerEmailer";

  public update(eventData: PaperIngestedEvent): void {
    console.log(
      `[${this.name}] Sending alerts for "${eventData.title}"...`,
    );
  }
}

Each subscriber implements the same interface but responds differently. The search updater handles indexing, while the emailer handles notifications.

Now connect everything:

const ingestionService = new PaperIngestionService();

const searchUpdater = new SearchIndexUpdater();
const emailer = new AuthorTrackerEmailer();

ingestionService.subscribe(searchUpdater);
ingestionService.subscribe(emailer);

ingestionService.ingestNewPaper(
  "DOC-1",
  "Low-Level Design in Node.js",
);

ingestionService.unsubscribe(emailer);

ingestionService.ingestNewPaper(
  "DOC-2",
  "Data Structures in Node.js Apps",
);

The first paper triggers both subscribers. After the emailer unsubscribes, the second paper triggers only the search updater.

The publisher never needs to know which concrete subscriber is responsible for which operation. It simply broadcasts the event to the objects that have subscribed.

This is the Observer Pattern in its most direct form.

5. Why Does Node.js Have EventEmitter?

The manual implementation works, but it requires us to manage subscriber collections, subscription methods, notification loops, and related edge cases ourselves.

Node.js provides a built-in abstraction for named events: EventEmitter, available from node:events.

An EventEmitter allows a component to emit a named event and other components to register listener functions for that event. Node.js uses this model throughout its APIs. For example, network servers can emit connection events, and streams can emit data-related events. See the official Node.js Events documentation.

Rather than passing observer objects that implement an update() method, the publisher exposes named events and consumers register callbacks.

The basic API is:

import { EventEmitter } from "node:events";

const emitter = new EventEmitter();

emitter.on("paper:ingested", (event) => {
  console.log("A paper was ingested:", event);
});

emitter.emit("paper:ingested", {
  id: "DOC-1",
  title: "Low-Level Design in Node.js",
});

Here, on() registers a listener for the event named "paper:ingested", and emit() triggers that event, passing the supplied payload to the listener.

The event name identifies what happened. The payload provides the relevant information.

You can think of the difference this way:

Manual Observer Pattern             Node.js EventEmitter

Publisher                           EventEmitter
    |                                    |
    | notify(event)                      | emit("paper:ingested", event)
    v                                    v
Subscriber.update(event)            Registered callback(event)

The concepts are closely related, but the interfaces differ. In the manual design, observers are objects governed by a common interface. With EventEmitter, observers can be ordinary functions registered for specific event names.

An event emitter is especially useful when a component produces multiple kinds of events or when different parts of an application need to respond to different event types.

To understand how Node.js’s EventEmitter works, let us build a simplified version ourselves.

An event emitter needs to answer three questions: Who is interested in a particular event? How can a new listener register its interest? When an event occurs, which listeners should be called? A simple data structure can solve the problem: a map whose keys are event names and whose values are collections of listener functions.

For example:

EventEmitter
     |
     v
Map of events
     |
     +-- "paper:ingested"
     |        |
     |        +-- Search index callback
     |        +-- Email notification callback
     |
     +-- "paper:deleted"
              |
              +-- Search index cleanup callback

This is a little different from our original Observer Pattern implementation. There, we stored subscriber objects in one collection. With an event emitter, listeners are grouped by event name, so a component can subscribe to paper ingestion events without automatically receiving paper deletion events.

The underlying idea remains similar: register interested parties and invoke them when the relevant event occurs.

Let’s build a small reusable implementation in TypeScript.

type Listener = (...args: any[]) => void;

class SimpleEventEmitter {
  private events = new Map<string, Listener[]>();

  public on(eventName: string, listener: Listener): this {
    const listeners = this.events.get(eventName) ?? [];

    listeners.push(listener);
    this.events.set(eventName, listeners);

    return this;
  }

  public off(eventName: string, listener: Listener): this {
    const listeners = this.events.get(eventName);

    if (!listeners) {
      return this;
    }

    // Remove the most recently registered matching listener.
    const index = listeners.lastIndexOf(listener);

    if (index !== -1) {
      listeners.splice(index, 1);
    }

    if (listeners.length === 0) {
      this.events.delete(eventName);
    }

    return this;
  }

  public emit(eventName: string, ...args: any[]): boolean {
    const listeners = this.events.get(eventName);

    if (!listeners || listeners.length === 0) {
      return false;
    }

    // Use a snapshot so subscription changes do not alter
    // the current iteration.
    for (const listener of [...listeners]) {
      listener(...args);
    }

    return true;
  }
}

This implementation intentionally focuses on the core mechanism. It is an educational example, not a complete replacement for Node.js’s built-in class.

Let’s understand the three methods and the decisions behind them.

on(): Register a Listener

public on(eventName: string, listener: Listener): this {
  const listeners = this.events.get(eventName) ?? [];

  listeners.push(listener);
  this.events.set(eventName, listeners);

  return this;
}

The caller provides an event name and a callback function.

For example:

emitter.on("paper:ingested", (event) => {
  console.log("Paper received:", event);
});

The emitter looks for the listener collection associated with "paper:ingested". If the collection does not exist yet, it creates an empty array. It then adds the callback to that array.

Conceptually, its internal state becomes:

"paper:ingested"
       |
       v
  [callback A, callback B]

Multiple listeners can subscribe to the same event. The emitter does not need to understand what these callbacks do. It only needs to retain their references.

The method returns this, which allows calls to be chained. For example, emitter.on("a", handlerA).on("b", handlerB) registers two listeners on the same emitter.

off(): Remove a Listener

public off(eventName: string, listener: Listener): this {
  const listeners = this.events.get(eventName);

  if (!listeners) {
    return this;
  }

  const index = listeners.lastIndexOf(listener);

  if (index !== -1) {
    listeners.splice(index, 1);
  }

  if (listeners.length === 0) {
    this.events.delete(eventName);
  }

  return this;
}

A listener must be removable when it is no longer interested in an event. For example, a service might stop listening after it has completed a task or when its lifecycle ends. The important detail is that callbacks are objects with identity. To remove a listener, the caller must provide the same function reference used during registration.

const onPaper = (event: any) => {
  console.log(event.title);
};

emitter.on("paper:ingested", onPaper);

// Later:
emitter.off("paper:ingested", onPaper);

Defining a new arrow function with identical code would not remove the original function, because it would be a different function reference.

This implementation also allows the same callback to be registered more than once. Calling off() removes one matching occurrence, rather than every occurrence.

emit(): Notify the Listeners

public emit(eventName: string, ...args: any[]): boolean {
  const listeners = this.events.get(eventName);

  if (!listeners || listeners.length === 0) {
    return false;
  }

  for (const listener of [...listeners]) {
    listener(...args);
  }

  return true;
}

This is the core of the event notification mechanism.

When the caller emits "paper:ingested", the emitter retrieves the callbacks associated with that event and invokes each one, passing along the event data. The spread syntax ...args allows the emitter to pass any number of arguments. In our application, we will pass a single structured event object. The method returns true when listeners were present and false when no listeners were registered. The array copy, [...listeners], creates a snapshot for the current notification. If a listener adds or removes subscriptions while an event is being processed, those changes will not modify this particular snapshot.

One important limitation is that any weakens TypeScript’s type checking. We use it here to keep the internal mechanism straightforward. For a production event system, a typed event map or a type-safe event-emitter library can associate each event name with its specific payload type.

We can now use our implementation with the paper ingestion scenario.

interface PaperIngestedEvent {
  id: string;
  title: string;
  timestamp: Date;
}

const emitter = new SimpleEventEmitter();

const onPaperIndexed = (event: PaperIngestedEvent) => {
  console.log(`[Search] Indexing "${event.title}"`);
};

const onAuthorAlert = (event: PaperIngestedEvent) => {
  console.log(`[Email] Sending alerts for "${event.title}"`);
};

emitter.on("paper:ingested", onPaperIndexed);
emitter.on("paper:ingested", onAuthorAlert);

emitter.emit("paper:ingested", {
  id: "DOC-1",
  title: "Low-Level Design in Node.js",
  timestamp: new Date(),
});

emitter.off("paper:ingested", onAuthorAlert);

emitter.emit("paper:ingested", {
  id: "DOC-2",
  title: "Data Structures in Node.js Apps",
  timestamp: new Date(),
});

Expected output:

[Search] Indexing "Low-Level Design in Node.js"
[Email] Sending alerts for "Low-Level Design in Node.js"
[Search] Indexing "Data Structures in Node.js Apps"

The first event invokes both listeners. After the email listener is removed, only the search listener receives the second event.

Notice what the emitter does not know: it does not know what indexing means, how email works, or why a particular paper is important. It simply maps event names to callbacks and invokes those callbacks.

That is the essential mechanism behind an event emitter.

6. Rebuild the Paper Ingestion Example Using EventEmitter

Let’s make the built-in event system part of the design. The following example uses an ES Module import. It requires a Node.js project configured for ES Modules, plus TypeScript and Node.js type definitions in the development environment.

import { EventEmitter } from "node:events";

interface PaperIngestedEvent {
  id: string;
  title: string;
  timestamp: Date;
}

class PaperIngestionService extends EventEmitter {
  public ingestNewPaper(paperId: string, title: string): void {
    const event: PaperIngestedEvent = {
      id: paperId,
      title,
      timestamp: new Date(),
    };

    console.log(`\n[Publisher] Ingesting: ${event.title}`);

    this.emit("paper:ingested", event);
  }
}

The important change is that PaperIngestionService extends EventEmitter.

It gains methods such as on(), once(), off(), and emit() without our having to implement listener management ourselves.

The ingestion service still owns the domain action: creating a paper ingestion event. It does not need to know which services will react to that event.

Now define the listeners:

const ingestionService = new PaperIngestionService();

const onPaperIndexed = (event: PaperIngestedEvent): void => {
  console.log(
    `[SearchIndexUpdater] Indexing "${event.title}"...`,
  );
};

const onAuthorAlert = (event: PaperIngestedEvent): void => {
  console.log(
    `[AuthorTrackerEmailer] Sending topic alerts for "${event.title}"...`,
  );
};

ingestionService.on("paper:ingested", onPaperIndexed);
ingestionService.on("paper:ingested", onAuthorAlert);

ingestionService.ingestNewPaper(
  "DOC-1",
  "Low-Level Design in Node.js",
);

ingestionService.off("paper:ingested", onAuthorAlert);

ingestionService.ingestNewPaper(
  "DOC-2",
  "Data Structures in Node.js Apps",
);

Expected output:

[Publisher] Ingesting: Low-Level Design in Node.js
[SearchIndexUpdater] Indexing "Low-Level Design in Node.js"...
[AuthorTrackerEmailer] Sending topic alerts for "Low-Level Design in Node.js"...

[Publisher] Ingesting: Data Structures in Node.js Apps
[SearchIndexUpdater] Indexing "Data Structures in Node.js Apps"...

The first event reaches both listeners. After off() removes the email listener, later events reach only the index listener.

Notice that we passed a named function, onAuthorAlert, to off(). This matters because removing a listener requires the function reference used when registering it. Writing a new inline arrow function with identical code would create a different function object and would not remove the original listener.

The Node.js documentation describes off() as an alias for removeListener().

Why Use Named Events?

Consider extending the publisher to emit different events:

this.emit("paper:ingested", event);
this.emit("paper:rejected", rejectionDetails);
this.emit("paper:deleted", { id: paperId });

A subscriber interested only in successfully ingested papers can register for "paper:ingested" and ignore the other events.

Named events create a boundary between the component that announces something and the components interested in that particular occurrence.

As an application grows, consistent event naming and typed payload definitions become valuable. For larger systems, you can define an event map or use a typed event-emitter abstraction so event names and payload types are checked together rather than annotating every callback independently.

7. Important EventEmitter Behavior: Events Are Synchronous by Default

One of the most common misconceptions is that Node.js’s EventEmitter automatically runs listeners asynchronously.

It does not.

When you call:

emitter.emit("paper:ingested", event);

Node.js invokes the registered listeners for that event synchronously, in their registration order. The emit() call normally does not return until those listener functions have been invoked. This behavior is documented in the Node.js Events guide.

For example:

import { EventEmitter } from "node:events";

const emitter = new EventEmitter();

emitter.on("update", () => {
  console.log("Listener");
});

console.log("Before");
emitter.emit("update");
console.log("After");

Output:

Before
Listener
After

The event is not placed into a background queue merely because emit() is called.

This distinction matters for performance. If a listener performs expensive synchronous work, it can delay the publisher and other work on the same JavaScript thread.

An asynchronous listener also needs careful treatment:

emitter.on("paper:ingested", async (event) => {
  await sendEmail(event);
});

The listener starts its asynchronous operation, but EventEmitter.emit() does not wait for the returned promise to settle. If notification delivery must be awaited, the application needs an explicit asynchronous orchestration design, or an appropriate queue or job system.

For the simple log-based example, synchronous listener invocation is perfectly fine. For real email delivery, index updates, and remote API calls, it is important to decide whether the publisher should wait for those operations or let them proceed independently.

8. on(), once(), off(), and Error Handling

The EventEmitter API offers several methods worth knowing.

on(eventName, listener) registers a listener that remains active until removed.

once(eventName, listener) registers a listener that runs at most once, then is automatically removed. This is useful for one-time initialization or for waiting for a particular event. See Node.js once() documentation.

off(eventName, listener) removes the specified listener. Keep a reference to the original callback so it can be removed correctly.

emit(eventName, ...args) invokes listeners registered for that event and passes the supplied arguments to them.

There is also a special behavior for the event named "error". If an EventEmitter emits "error" and no listener is registered for it, Node.js throws the error. Applications using emitters for operations that may fail should handle errors deliberately rather than treating "error" like an ordinary notification event.

Also, avoid registering listeners repeatedly without removing them when their lifetime ends. Excess listeners can indicate a memory leak or an accidental subscription duplication. Node.js provides listener-counting and inspection methods to help diagnose these issues.

9. Observer Pattern, EventEmitter, and Message Queues Are Not the Same Thing

These mechanisms are related, but they solve problems at different levels.

The manual Observer Pattern manages relationships between a publisher object and observer objects. It is useful when you want an explicit interface, typed observer instances, and full control over subscription behavior.

Node.js EventEmitter is a practical in-process event mechanism. It provides named events and listener management, making it convenient for components that communicate within the same Node.js runtime.

A message broker or durable queue, by contrast, is designed for communication and processing beyond a simple in-memory callback relationship. Depending on the technology and configuration, it can provide buffering, persistence, consumer coordination, retries, and communication between separate processes or services.

For example, emitting a paper ingestion event in memory does not guarantee that an email will be delivered if the process crashes. The event is not automatically persisted for later replay. Similarly, separate Node.js processes do not share an ordinary EventEmitter instance.

For low-latency reactions within one process, EventEmitter is often sufficient. For reliable background processing, cross-process communication, or durable delivery guarantees, a queue or messaging system may be more appropriate.

Conclusion

The Observer Pattern addresses a common design problem: one component needs to announce an event, but it should not be tightly coupled to every component that reacts to it.

In the paper ingestion example, the publisher announces that a paper has been ingested, while the search updater and emailer independently react to that event. The manual implementation demonstrates the core pattern through subscriber interfaces and explicit notification. Rebuilding it with Node.js EventEmitter shows how named events and callbacks provide a practical event-driven implementation.

The key engineering decision is choosing the appropriate communication mechanism. Use a simple observer relationship when explicit object subscriptions are useful. Use EventEmitter for in-process event notifications. Use a queue or broker when the application needs reliability, buffering, or communication beyond the current process.

The central idea remains the same: announce what happened, publish the relevant event data, and let interested components decide how to react.