Do your Node.js back-ends really need service discovery?

Service discovery exists because HTTP calls an address. To call service B you need a host and a port, and because instances come and go, you need something keeping a live map of where a healthy B is right now — Consul, etcd, Eureka, DNS-SD, or your platform's registry. Route calls through a message queue instead and the question dissolves: a service reads from its own named queue, so the queue name is the address and there's no host to resolve. That's a real simplification, and it costs you things worth knowing about before you choose it.

What service discovery is really for

Discovery is the answer to "where is a healthy instance of B?", and it's usually paired with health checks and a load balancer or mesh. It's the right tool when:

• You have a polyglot fleet where many kinds of clients need to locate services.
• You're already invested in a service mesh and want its traffic policies, mTLS and observability.
• You need discovery for things beyond RPC — config distribution, leader election, distributed coordination.

If that's you, keep it; it earns its place. A queue replaces the addressing job only.

What changes with a queue

With @imqueue, a service consumes from a queue named after it, and instances of that service compete on the same queue:

• All instances read the same named queue, so which instance handles a call is decided by consumption, not by a registry.
• Starting or stopping instances changes nothing anyone has to discover — they attach to or detach from the same queue.
• There's no live host map, and no health-check plumbing feeding a registry.

The caller just uses a generated client:

import { user } from './clients/index.js';

const client = new user.UserClient({ callTimeout: 5000 });
await client.start();

const found = await client.get('42'); // no host, no port, no registry lookup

The caller never knows or cares how many instances of the User service exist, or where they run. Load balancing without a load balancer covers the distribution side of the same mechanism.

The nice consequence: boot order stops mattering

Order-independent boot is the part people don't expect. Because an @imqueue call is a message on a queue rather than a connection to a host, a caller can send before the callee exists. The message waits. Services can start in any order, and a service that isn't up yet simply accumulates work until a consumer appears.

That removes a whole category of orchestration: no readiness gates between services just so A doesn't crash-loop while B boots, no retry-with-backoff on startup, no dependency ordering in your compose file.

One caveat that matters: this holds for pre-generated static clients, the ones you commit. A dynamic client created at runtime with IMQClient.create() has to ask the running service for its description, so it does require the target to be up. If order-independence is the property you want, generate your clients ahead of time.

What replaces each job discovery was doing

Discovery's job	With a queue
Find a host for B	Nothing to find — the queue name is the address
Balance across B's instances	Instances compete on the queue
Notice B is unhealthy and route around it	Nothing routes; unconsumed work waits on the queue
Notice B is gone entirely	Nothing tells you — see below
Distribute config, elect leaders	Not covered; still your problem

Four of five rows get simpler. The fourth is the one to think hard about.

The honest cost: "where is B" becomes "is B ever coming?"

A registry with health checks gives you an explicit answer to "is B alive". A queue gives you no such thing, and that trade is the real content of this decision.

With HTTP plus discovery, a call to a service with no healthy instances fails fast and loudly — connection refused, or a 503 from the mesh. With a queue, the same call is indistinguishable from a call to a service that's merely busy. It waits. Two consequences:

• Set callTimeout. It's unset by default, which means a call to a service that never answers stays pending forever. This is the single most important option to set in production, and the queue model is exactly why.
• A timeout is not a diagnosis. IMQ_RPC_CALL_TIMEOUT tells you nobody answered in time. It doesn't distinguish "still booting", "overloaded", "crash-looping" and "never deployed". A registry would have told you which.

So you don't escape observability work — you relocate it. Instead of registry health, you watch queue depth: @imqueue's optional metrics server exposes a queue_length metric, and a queue growing without bound is the signal that a consumer has stopped consuming.

Read that metric carefully, though. queueLength() excludes messages that aren't due yet and messages currently leased under safe delivery, so it isn't a measure of outstanding work — and it returns 0 when there's no writer connection, which makes "disconnected" look identical to "empty". Alert on growth, not on absolute depth, and don't treat zero as healthy on its own.

A fair accounting of the rest

• You depend on the queue being available the way you'd depend on a registry or mesh. With @imqueue that's Redis, in the path of every internal call — a stateful dependency whose availability becomes your RPC layer's availability. For most teams it's infrastructure they already run; it's still a dependency you should reason about rather than wave through.
• Delivery is at-least-once. Because a message can be delivered twice, exposed methods should be idempotent. That's a design constraint HTTP-plus-discovery doesn't impose. See what guaranteed delivery costs.
• Nothing drains in-flight work on shutdown. A worker killed mid-handler loses that message. Graceful shutdown and zero-drop deploys works through what closing that gap actually takes.
• Non-RPC needs are untouched. Config distribution, leader election and coordination still need the right tool; a queue doesn't replace them.
• Cross-language fleets may still want a language-neutral discovery story — gRPC is the better answer there.

So does your Node.js back-end need service discovery?

A short test. You probably don't need a discovery layer if:

• Your back-end services are all Node.js or TypeScript.
• The only reason you were about to install Consul is "so my services can find each other to make calls".
• You already run Redis, or don't mind adding it.
• You can make your handlers idempotent.

You probably do still need one if:

• Your fleet is polyglot, or clients outside your control need to locate services.
• You want a mesh's traffic policy, mTLS or tracing.
• You need discovery for config, coordination or leader election as well.
• Fail-fast semantics matter more to you than buffered ones — some systems genuinely want the call to explode immediately rather than wait.

Frequently asked questions about service discovery in Node.js

Is a message queue a replacement for Consul or etcd?

For service-to-service addressing, largely yes — the queue name is the address. For config distribution, leader election and coordination, no. Those are separate jobs a queue doesn't do.

How do I know a service is healthy without a registry?

You watch the queue rather than the service. @imqueue can expose a queue_length metric; sustained growth means a consumer has stopped keeping up. You don't get a registry's per-instance health view, and you should set callTimeout so callers fail rather than hang.

What happens if a service is down when someone calls it?

The message waits on its queue until a consumer appears, so the call isn't lost. The risk is the opposite of HTTP's: instead of failing fast, it can wait indefinitely — which is why callTimeout matters.

Does this work across multiple machines?

Yes. Instances anywhere that can reach the same Redis compete on the same queue, so horizontal scaling needs no addressing changes.

Do I still need a load balancer?

Not for internal service-to-service calls; competing consumers handle distribution. You'll still want something in front of your HTTP edge.

Doesn't this just move the single point of failure to Redis?

It concentrates the dependency, yes — honestly, that's the trade. A registry or mesh is also a critical dependency; the question is which one you'd rather operate, and whether you're already running it.

---

If a queue-based model sounds like it fits, Getting Started shows how calls work with no addressing on your side, and horizontally scalable Redis broker covers what happens when one Redis isn't enough. Shipping inside a closed-source product? See commercial licensing & support.