DISTRIBUTED SYSTEMS REFERENCE ARCHITECTURE RABBITMQ + REDIS PUB/SUB

XrossTalk

Real-Time Feature Flag Control & User Presence Microservices Architecture

ROLE Backend & Systems Architect

CORE TECHNOLOGIES

RabbitMQ Redis WebSockets FastAPI (Python)

PRIMARY HIGHLIGHT Cross-server event streaming via RabbitMQ queues Sub-millisecond presence tracking in Redis

LINKS & ACCESS

GITHUB arrow_outward

01. Context & Overview

XrossTalk is a reference implementation of the event-driven, real-time microservices architecture patterns used in production systems.

Built around a containerized polyglot stack—Node.js (Express + WebSockets), Python (FastAPI), RabbitMQ, and Redis—XrossTalk demonstrates decoupled inter-service messaging, distributed presence tracking, and instantaneous feature flag propagation.

The architecture organizes responsibilities across two specialized backend services and an interactive frontend:

Server-Comet (Node.js + Express + TypeScript + WebSockets on port 5000): Manages persistent duplex client connections, streams real-time status updates, and handles user presence.
Server-Orbit (Python + FastAPI on port 5001): Powers admin operations, feature flag configuration, and asynchronous message publishing.
RabbitMQ: Serves as the central message broker orchestrating cross-server message queuing between Server-Orbit and Server-Comet.
Redis: Acts as the dedicated high-throughput presence engine, recording live connected users, session heartbeats, and historical activity logs.
Frontend (React + Vite + Tailwind CSS + ShadCN UI on port 3000): Served via NGINX, providing an admin dashboard to toggle flags and monitor presence.

02. The Constraints & Needs

Real-time multi-service environments face several core distributed systems challenges:

Immediate Feature Flag Propagation: In traditional architectures, feature flags rely on client polling or cached REST endpoints, delaying rollout propagation by seconds or minutes. XrossTalk requires instantaneous broadcast to all active clients the moment an admin flips a toggle.
Polyglot Service Decoupling: Interconnecting a high-concurrency Node.js WebSocket gateway with a Python data processing service via direct HTTP creates brittle dependencies and cascading failure risks during traffic surges.
High-Frequency Ephemeral Presence: Tracking live users, connection/disconnection lifecycles, and audit activity logs requires sub-millisecond writes that would saturate traditional relational database write heads.

FeatureFlagEventPayload

EVENT CONTRACT

// Contract schema definition

{

"event_type": *req <string> // Event discriminator (e.g. 'flag.toggled', 'presence.ping')

"flag_id": *req <string> // Unique feature flag key (e.g. 'beta_feature_v2')

"enabled": *req <boolean> // Updated flag state toggled by administrator

"updated_by": *req <string> // Admin identifier issuing the state transition

"timestamp": *req <epoch_ms> // UTC millisecond timestamp of the emission

"metadata": <object> // Optional tenant routing rules or environment targets

}

03. System Architecture & Data Flow

XrossTalk is organized as a clean monorepo orchestrated through Docker Compose:

xrosstalk/
├── apps/
│   ├── frontend/      # React + Vite + Tailwind + ShadCN (served via NGINX)
│   ├── server-orbit/  # FastAPI Python server (REST + AMQP producer)
│   └── server-comet/  # Express + TypeScript server (WebSocket gateway + AMQP consumer)
├── infra/
│   ├── docker/        # Shared container configurations
│   └── dev/           # Local environment variables & secrets
├── docker-compose.yml
└── README.md

The system separates ingestion, message brokering, and live client delivery into a clear asynchronous pipeline:

ARCHITECTURE SCHEMATIC

XrossTalk Event-Driven Mesh Pipeline

PIPELINE FLOW

Admin Dashboard Flag Toggle REACT + SHADCN (PORT 3000)

Admin user flips a feature flag toggle in the UI, dispatching a secure REST mutation to Server-Orbit.

arrow_downward

Server-Orbit Ingestion & Validation FASTAPI (PORT 5001)

Validates admin credentials, updates flag configuration state, and immediately emits an event to RabbitMQ.

arrow_downward

RabbitMQ Message Broker Queuing AMQP QUEUES

Brokers cross-server delivery, decoupling Server-Orbit from downstream consumers without synchronous HTTP blocking.

arrow_downward

Server-Comet WebSocket Broadcast NODE.JS + TS (PORT 5000)

Consumes AMQP event from RabbitMQ and fans out the feature flag payload over persistent WebSockets to all connected client browsers.

arrow_downward

Redis Presence & Activity Tracking REDIS IN-MEMORY ENGINE

Records user connection states, tracks active heartbeats, and streams activity audit logs to the monitoring dashboard.

04. Protocol & Sequence Lifecycle

The trace below illustrates a real-time feature flag rollout scenario: an administrator toggles an experimental feature, the state travels through RabbitMQ to Server-Comet, and all connected user clients receive the updated flag instantly while presence and audit logs are recorded.

PROTOCOL LIFECYCLE

Live Feature Flag Rollout & Presence Trace

SEQUENCE TRACE

Admin UI

Server-Orbit (Py)

RabbitMQ

Server-Comet (Node)

#1 Admin UI → Server-Orbit (Py) : POST /flags/{id}/toggle: Enable new feature flag

6ms

#2 Server-Orbit (Py) → RabbitMQ : Publish flag.toggled payload to AMQP exchange

2ms [Non-blocking publish]

#3 RabbitMQ → Server-Comet (Node) : Deliver message to active consumer queue

3ms

#4 Server-Comet (Node) → Admin UI : WSS: Broadcast flag.toggled to all active clients

4ms [Instant UI enablement]

#5 Admin UI → Server-Comet (Node) : WSS: Send client presence heartbeat ping

1ms

#6 Server-Comet (Node) → Server-Orbit (Py) : Redis SET / EXPIRE: Update active user lease & log entry

2ms [Sub-millisecond presence]

05. Benchmark & Evaluation Matrix

Comparing traditional polling approaches with XrossTalk’s event-driven RabbitMQ + WebSocket architecture:

ARCHITECTURE MATRIX

System Architecture Decisions & Trade-Offs

Comparative evaluation across design constraints and implementations

TRADE-OFFS

swipe Swipe horizontally to inspect full matrix

Architectural Dimension	Conventional Approach	XrossTalk Solution	Result & Trade-Off
Feature Flag Rollout Delay	3,000–5,000ms periodic HTTP client polling	<15ms AMQP + WebSocket push fan-out	Instant rollout; zero polling traffic overhead
Inter-Service Coupling	Synchronous REST calls with cascading failure risks	RabbitMQ AMQP message broker	Decoupled asynchronous message passing and queue persistence
Presence Tracking Overhead	Relational database writes on every client heartbeat	Redis in-memory hashes with TTL leases	Sub-millisecond presence lookup; automatic disconnect expiration
Stack Portability	Manual environment and multi-runtime configuration	Single-file Docker Compose orchestration	Identical local development and cloud VPS deployments

06. Key Engineering Learnings

Leverage Polyglot Strengths: Use Node.js for high-concurrency WebSocket connection management where event loops excel, and Python (FastAPI) for structured business APIs and data processing.
Decouple Services with Message Queues: Direct service-to-service HTTP calls introduce fragile temporal dependencies. Placing RabbitMQ between Server-Orbit and Server-Comet ensures resilient message delivery even under consumer restarts.
Isolate Presence in In-Memory Stores: Ephemeral states such as user connection presence, heartbeat leases, and live activity streams belong in Redis, sparing relational databases from write saturation.
Reproducible Containerized Workflows: Defining every service, port mapping (3000, 5000, 5001), and networking layer in docker-compose.yml ensures development mirrors production VPS deployments (Oracle Cloud VPS + NGINX + Certbot).

arrow_back Return to All Projects ↑ Top of Page