You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/adrs/adr-001-websocket-scalability.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,24 +6,33 @@ The `flight-tracker-event-server` currently sends flight updates directly to cli
6
6
## Decision
7
7
Refactor the application so that the `PingEventPublisher` publishes flight events to a Kafka topic. A new dedicated component will consume these events and manage active WebSocket sessions for message delivery.
8
8
9
+
Additionally, we will implement feature flags to control the WebSocket delivery mechanism, allowing the system to run in different deployment configurations:
10
+
-**Monolithic Mode**: All components run in the same service with in-memory WebSocket sessions
11
+
-**Decoupled Mode**: WebSocket delivery runs as a separate component consuming from Kafka
12
+
9
13
This decision enables separation of responsibilities and prepares the system for a future migration to a STOMP-based architecture (e.g., RabbitMQ) if scale demands increase.
10
14
11
15
## Justification
12
16
-**Time-to-market**: quick delivery without frontend changes
13
17
-**Decoupling**: separates event generation from delivery logic
14
18
-**Reuses existing infrastructure**: Kafka is already in place
15
19
-**Low impact**: avoids protocol changes or client modifications for now
20
+
-**Deployment Flexibility**: allows gradual transition between deployment models
21
+
-**Reduced Complexity**: initial implementation can stay within the same service
16
22
17
23
## Alternatives Considered
18
24
-**STOMP Broker with RabbitMQ**: powerful but requires client refactor and more setup
19
25
-**Redis Streams/PubSub**: simple, fast, but with delivery and clustering limitations
20
26
-**Optimizing the current implementation**: fast but not future-proof
27
+
-**Immediate Service Split**: would require more upfront work and coordination
21
28
22
29
## Consequences
23
30
- The system becomes modular and more scalable
24
31
- Kafka enables better backpressure and failover handling
25
32
- Prepares for a transition to STOMP when scale justifies it
26
33
- A new WebSocket delivery component must be monitored closely
34
+
- Feature flags add complexity but provide deployment flexibility
35
+
- Allows for gradual migration of WebSocket handling to a separate service
0 commit comments