Existing approach — web service + real-time

The pieces added for the real-time feature (orange) grow to as much as the main body

Existing approach — web service + real-time The pieces added for the real-time feature (orange) grow to as much as the main body Client app · Architecture component Client app L7 LB / gateway · Architecture component L7 LB / gateway sticky LB · Architecture component sticky LB API servers ×N · ASP.NET Core · stateless · Architecture component API servers ×N ASP.NET Core · stateless WebSocket ×N · connections only, no logic · Architecture component WebSocket ×N connections only, no logic service discovery · xDS / Consul · Architecture component service discovery xDS / Consul Redis lock · distributed · ordering · Architecture component Redis lock distributed · ordering Redis pub/sub · real-time fan-out detour · Architecture component Redis pub/sub real-time fan-out detour Domain ×N · gRPC server · Architecture component Domain ×N gRPC server HTTP gRPC + sidecar location lookup registration serialize real-time publish push

The orange pieces the real-time feature bolts on

  • • sticky LB + WebSocket servers: hold customer connections only, no logic
  • • Redis pub/sub (real-time fan-out detour): the server doesn't know which WS the client is on, so it publishes the status and the subscribing WS pushes it — drawn one-way API→pub/sub→WS, but WS↔pub/sub and pub/sub↔API are both bidirectional (subscribe + publish)
  • • Redis distributed lock: several servers touch the same order/conversation at once → serialize for ordering

Main body (blue) + discovery (gray)

  • • API servers (ASP.NET Core, stateless) ↔ Domain servers (gRPC server) over gRPC + mesh sidecar
  • • service discovery (xDS / Consul): the API does location lookup, the Domain server registers
  • • Sticky LB, WebSocket, pub/sub detour, distributed lock, mesh/discovery — five pieces bolted on just for real-time