the Client connects only to Session · API, Matchmaking, Play talk server-to-server over RouteMesh
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Semantic radar needs more MAP space.
Client-facing edge
• The only role the Client connects to directly is Session; API, Matchmaking, and Play communicate over server-to-server channels and RouteMesh.
• Both Player Clients (×2) and the Observer Client (×1) open one STREAM connection to the Session Servers (mermaid subgraph Clients).
• Counts (mermaid subgraph Servers): Session ×2, API ×2, Play ×2, and a single Matchmaking server ×1 (not assumed to be a singleton).
Logical channels (mermaid drew all links undirected ---)
• bingo.api (Session→API): ClientServer channel — Session and Play call the authentication/player-record API.
• bingo.matchmaking (API→Matchmaking): RouteMesh — API calls the level bucket's Matchmaker Instance Spot.
• bingo.play (Session→Play and API→Play): RouteMesh — API and Session find the Room/Actor; the Play node processes object messages and Logical Multicast.
• STREAM delivers client requests, responses, and server push over one connection.