FeathersJS Real-time Event Broadcasting in Serverless Deployments

Real-time Broadcasting in Stateless Architectures

In a serverless deployment, the Redis adapter ensures that an event emitted by one isolated function instance is broadcast to all other active instances. However, it does not provide a persistent state for clients or event history.

Redis Adapter and Cold Starts

The Redis adapter maintains consistent delivery across cold starts, but not continuity. When a serverless instance cold-starts, it establishes a new connection to the Redis pub/sub channel. Any event emitted while that specific instance was inactive is lost to that instance; the adapter does not "replay" missed events to newly spawned functions.

Furthermore, because serverless functions are stateless, the WebSocket connection itself is typically managed by a gateway (like AWS API Gateway WebSocket API) or a separate proxy. The Redis adapter simply tells the current function instance to push a message to the gateway for a specific client ID.

Alternatives to Persistent External Dependencies

There are no built-in FeathersJS mechanisms for cross-instance broadcasting that avoid an external dependency. Because serverless instances share no memory or network socket, a "third party" must act as the message bus. If a persistent Redis instance is cost-prohibitive, consider these alternatives:

• Provider-Managed WebSocket Services: Use services like AWS AppSync or Azure Web PubSub. These move the connection state and broadcasting logic entirely out of your FeathersJS code and into the cloud provider's infrastructure.
• Client-Side Polling: For extremely low-traffic apps, replacing real-time events with short-polling (requesting updates every X seconds) removes the need for a pub/sub layer entirely.
• Database-Driven State: Use a database with "Change Data Capture" (CDC) or listeners (e.g., MongoDB Change Streams or PostgreSQL NOTIFY) to trigger events, though this effectively replaces Redis with another persistent dependency.

Verification Steps

To verify the behavior of your current setup, you can simulate a distributed environment locally:

1. Start two separate FeathersJS processes on different ports, both connected to the same Redis instance.
2. Connect a client to Process A and another to Process B.
3. Emit a service event from Process A and verify that the client on Process B receives it.
4. Shut down Process B, emit an event, and restart Process B. Confirm that the client on Process B does not receive the event emitted during the downtime.

Diagnostic Detail Needed: Which serverless provider and WebSocket gateway are you using? The recommendation changes significantly if you are using a managed gateway (like AWS) versus a containerized serverless approach (like Google Cloud Run).