Rank 14 of 28 · Tier B · app/gateways/Stack: Go, Kafka, Cassandra, WebSocket, Docker Compose
Scope: 48,582 lines of Go across three gateways plus a test harness
Why this ranks here. Three independently-built WebSocket gateways, each
with its own session, presence, dispatch, and event-bus layers over Kafka and
Cassandra. It is genuine realtime-fan-out engineering at volume. It ranks
below Tier S because it is largely superseded by GlobalChatService — but the
layer decomposition is the reusable interview material.
Three gateways, 48,582 lines, one event bus
Each gateway independently implements session, presence, dispatch and event-bus layers over Kafka and Cassandra. The repetition is the honest part of the story: three implementations of one pattern is what a shared library exists to prevent.
The three gateways
Gateway
Lines
Files
billboard_gateway
19,928
37
dating_gateway
17,118
33
mating_gateway
7,628
21
testing (harness)
3,908
12
The layer decomposition (repeated in each)
Each gateway is built from the same named layers — which is the point worth
making in an interview, because it is a deliberate architecture repeated
three times, not three ad-hoc services:
connection.go ── raw WebSocket lifecycle
connClient.go ── per-connection client state
session.go ── session identity and resumption
sessClient.go ── session-scoped client handle
presence.go ── online/offline, TTL
dispatch.go ── inbound message routing
eventbus.go ── internal pub/sub
kafka.go ── cross-service event transport
cassandra.go ── durable state
dao.go ── data access
payload.go ── wire format
errorLord.go ── centralized error taxonomy
adapter.go ── external service adapters
handlers/ ── chat, profile, photo, upload
Separating connection from session from presence is the correct
decomposition and is exactly what a "design a chat system" interview wants to
hear: a connection is a TCP/WS object that dies constantly; a session survives
reconnects; presence is a derived, TTL'd view over sessions.
Local operability
app/gateways/docker-compose.yml + Makefile bring the whole trio up locally
against Kafka and Cassandra. Being able to run your distributed system on a
laptop is an underrated interview answer.
Interview surface this opens
Connection vs session vs presence, and why conflating them breaks reconnects
Event bus in-process vs Kafka across services — where the boundary belongs
Error taxonomy design (errorLord.go) and why centralized error typing pays off
Running a multi-broker, multi-node stack locally for development