Apart from working on the design presentation and constraints, my main focus this week was fully fleshing out the server communication for our Catan board. I finalized the architecture for how the Raspberry Pis (host and joiner) will communicate with each other and the cloud, and translated that into a clear data flow design.
On the host side, I detailed the Go native application modules: the game engine and state machine that keeps tracks of players’ turns,, the Pion WebRTC connection layer (handling the DataChannel and ICE), the snapshot manager for serializing the game state, and the event log for recording moves. I also added a local persistence layer using SQLite in WAL mode so the host can write both versioned snapshots and an append-only event log. To bridge this with the cloud, I built out the concept of an uploader that asynchronously pushes periodic snapshots and event batches to the Save Service API. The host also interfaces with an LCD display to show the game code, making setup clear for the user.
On the joiner side, I designed a corresponding Go native application with a lighter module set: the same game engine and WebRTC connection, plus a “catch-up” module that can pull snapshots and missing events from the cloud if the joiner reconnects or rehosts. For user interaction, the joiner will take game code input through a USB numeric keypad that they briefly connect to the Raspberry Pi. While not required, I included an optional SQLite cache so the joiner can locally store recent state for failure recovery.
For the cloud services, I defined the Save Service API endpoints (/games, /save, /events, /snapshot, /resume) that handle game persistence and recovery. I also specified Postgres as the structured store for events and object storage for snapshots, ensuring that the game can always be resumed if a Pi disconnects or fails. Alongside this, I integrated the signaling server (over WebSocket/HTTPS) for SDP/ICE exchange and NAT traversal support via STUN/TURN (coturn), with all traffic secured by TLS. The latter is required by WebRTC applications to run smoothly and for firewall recovery.
Finally, I documented the resilience and recovery flow: the host maintains an authoritative state locally and periodically syncs it to the cloud; if the host drops, another board can fetch the most recent snapshot and events to continue the game without loss of progress. This ties the user-facing hardware, Pi software modules, and cloud services into a complete, robust communication system.
While some of the above requirements are included in the case we are able to achieve our “ideal” product (i.e. they are not required for MVP), I included them in the preliminary block diagram. As for next steps, I plan to refine this setup and also begin implementing the Go app skeleton on the Raspberry Pi, starting with WebRTC setup using Pion.
Below is a detailed diagram of the above information, and below that is a more cleaned up but less dense diagram.

