REDIS Streams

Andi Lamprecht ·2026-05-11· 2 min read· Accepted

Real-time airspace updates via WebSockets with Redis and PostgreSQL

Context

Themis needs to provide airspace updates to other systems. To meet this requirement, a websocket interface is provided. Clients create a subscription by connecting to a websocket endpoint to listen for updates.

An additional consideration is the reliability and resiliency of Redis as an in-memory store. PostgreSQL serves as the canonical source of truth for airspace data. Redis functions as a “hot path” for broadcasting new updates to interested clients based on their existing subscriptions.

Invalid Image Path

Decision

Using Redis Streams as an append-only log, all updated airspace will be stored when received. Each websocket process will read from Redis to get updates as they come in and will notify the matching active subscriptions/listeners.

Consequences

• Message retention for replay: Allows for more flexible updating strategies, letting clients pick up where they left off in case of disconnections.
• Flexible subscription management: Redis supports multiple subscribers, whether it’s 1 or 1000.
• Resiliency: PostgreSQL serves as the durable, stateful store and source of truth for all data. Redis functions as a secondary, in-memory store for real-time notifications.

Failure Scenarios

In the case that Redis goes down, clients can fall back to the existing HTTP endpoint to retrieve airspace data based on specified criteria.

Alternatives Considered

• Redis Pub/Sub, RabbitMQ: Good for pushing messages but don’t inherently support message replay.
• GCP Pub/Sub: Supports message replay and holds messages for disconnected consumers, but introduces tighter coupling with GCP.
• Apache Kafka: While robust and feature-rich, Kafka’s complexity in setup and maintenance could be considered overkill for our specific real-time update delivery needs.