Why Strata

Strata is a microservice framework for Node.js that replaces REST with message queues. If you've used Express, you already know how Strata works -- contexts are routers, operations are routes, and middleware is middleware. The difference is that instead of HTTP requests between services, Strata uses message queues as the communication layer.

The term "microservice" is loose here. Strata gives you tools for building services. How micro they are is entirely up to you.

The Express Analogy

Express	Strata	Purpose
express()	StrataService	The application instance
Router	StrataContext	Groups related handlers together
Route/endpoint	Operation	A single unit of work
app.use()	useMiddleware()	Pluggable request/response processing

The API should feel familiar. You create a service, register contexts that handle operations, and add middleware to modify requests and responses. The mental model is the same -- the transport is different.

Why Message Queues

In a REST architecture, services communicate directly. Service A makes an HTTP call to Service B. That means Service A needs to know where Service B is, needs Service B to be running right now, and gets one response from one instance. Message queues remove all three of those constraints.

Decoupling

Services don't need to know where other services live. A client pushes a message onto a queue. One or more service instances read from that queue. The client never needs to know how many instances exist, what hosts they're on, or how the work gets distributed. It just writes to the queue and moves on.

Resilience

If a service goes down, messages queue up instead of failing. When the service comes back, it picks up right where it left off. No lost requests, no retry logic, no circuit breakers. The queue absorbs the shock.

Scalability

Need to process messages faster? Add more service instances reading from the same queue. Each message goes to exactly one instance -- no load balancer needed, no sticky sessions, no coordination. The queue handles distribution automatically. Scale up by starting more processes, scale down by stopping them.

                                                  /-> Service Instance 1
Client -> [ Message3, Message2, Message1 ] -------->  Service Instance 2
                                                  \-> Service Instance 3

Each instance pops one message at a time. No two instances get the same message. Add or remove instances at any time without reconfiguring anything.

What Makes Strata Opinionated

Strata is opinionated about the things that matter for service communication and indifferent about the things that don't. Specifically:

• The protocol is defined. Request and response envelopes have a fixed structure. No bikeshedding over payload formats, error shapes, or metadata conventions. See The Protocol for the full specification.
• Backends are pluggable. Redis lists, Redis Streams, or bring your own. The service code doesn't change when you swap backends.
• Middleware has clear hooks. Three hooks (beforeRequest, success, failure) with a defined calling order. No ambiguity about when your code runs.
• Service groups handle scaling. Multiple instances of the same service share a queue automatically. Horizontal scaling is a deployment concern, not a code concern.

What Strata does not care about: how you structure your business logic, what ORM you use, how you organize your files, or what patterns you follow internally. That's your domain.

Backend Agnostic

Strata v2 introduced a pluggable backend system. The framework doesn't assume Redis, or any specific queue technology. Built-in backends include Redis lists, Redis Streams, and a null backend for testing. You can also write your own by implementing the BaseStrataBackend interface.

Your service code stays the same regardless of which backend you choose. The backend is a configuration choice, not an architectural one.