I spent 10 months building a distributed implementation of the board game Codenames, and I wanted to share what I learned about Rust, real-time management and the trade-offs I had to navigate.

Why this project?

I'm a web developer who wanted to learn and improve on some new technologies and complicated stuff. I chose Codenames because it's a game I love, and it presented interesting technical challenges: real-time multiplayer, session management, and the need to coordinate multiple services.

The goal wasn't just to make it work, it was to explore different languages, patterns, and see where things break in a distributed system.

Architecture overview:

Frontend:

• Vue.js 3 SPA with reactive state management (Pinia)
• Vuetify for UI components, GSAP for animations
• WebSocket clients for real-time communication

Backend services:

• Account/Auth: Java 25 (Spring Boot 4)
  • Spring Data R2DBC for fully async database operations
  • JWT-based authentication
  • Reactive programming model
• Game logic: Rust 1.90 (Actix Web)
  • Chosen for performance-critical game state management
  • SeaORM with lazy loading
  • Zero-cost abstractions for concurrent game sessions
• Real-time communication: .NET 10.0 (C# 14)
  • SignalR for WebSocket management
  • Excellent built-in support for real-time protocols
• API gateway: Spring Cloud Gateway
  • Request routing and load balancing
  • Resilience4j circuit breakers

Infrastructure:

• Google Cloud Platform (Cloud Run)
• RabbitMQ for async inter-service messaging
• MySQL databases (separate per service)
• Hexagonal architecture (ports & adapters) for each service

The hard parts (and what I learned):

1. Learning Rust (coming from a Java background):

This was the steepest learning curve. As a Java developer, Rust's ownership model and borrow checker felt completely foreign.

• Fighting the borrow checker until it clicked
• Unlearning garbage collection assumptions
• Understanding lifetimes and when to use them
• Actix Web patterns vs Spring Boot conventions

Lesson learned: Rust forces you to think about memory and concurrency upfront, not as an afterthought. The pain early on pays dividends later - once it compiles, it usually works correctly. But those first few weeks were humbling.

2. Frontend real-time components and animations:

Getting smooth animations while managing WebSocket state updates was harder than expected.

• Coordinating GSAP animations with Vue.js reactive state
• Managing WebSocket reconnections and interactions without breaking the UI
• Keeping real-time updates smooth during animations
• Handling state transitions cleanly

Lesson learned: Real-time UIs are deceptively complex. You need to think carefully about when to animate, when to update state, and how to handle race conditions between user interactions and server updates. I rewrote the game board component at least 3 times before getting it right.

3. Inter-service communication:

When you have services in different languages talking to each other, things fail in interesting ways.

• RabbitMQ with publisher confirms and consumer acknowledgments
• Dead Letter Queues (DLQ) for failed message handling
• Exponential backoff with jitter for retries
• Circuit breakers on HTTP boundaries (Resilience4j, Polly v8)

Lesson learned: Messages will get lost. Plan for it from day one.

Why polyglot?

I intentionally chose three different languages to see what each brings to the table:

• Rust for game logic: Performance matters when you're managing concurrent game sessions. Memory safety without GC overhead is a big win.
• Java for account service: The authentication ecosystem is mature and battle-tested. Spring Security integration is hard to beat.
• .NET for real-time: SignalR is genuinely the best WebSocket abstraction I've used. The async/await patterns in C# feel more natural than alternatives.

Trade-off: The operational complexity is significant. Three languages means three different toolchains, testing strategies, and mental models.

Would I do polyglot again? For learning: absolutely. For production at a startup: surely not.

Deployment & costs:

Running on Google Cloud Platform (Cloud Run) with careful cost optimization:

• Auto-scaling based on request volume
• Concurrency settings tuned per service
• Not hosting a public demo because cloud costs at scale are real

The whole setup costs me less than a Netflix subscription monthly for development/testing.

What would I do differently?

If I were starting over:

1. Start with a monolith first to validate the domain model, then break it apart
2. Don't go polyglot until you have a clear reason - operational complexity adds up fast
3. Invest in observability from day one - distributed tracing saved me countless hours
4. Write more integration tests, fewer unit tests - in microservices, the integration points are where bugs hide

Note: Desktop-only implementation (1920x1080 - 16/9 minimum recommended) - I chose to focus on architecture over responsive design complexity.

Source code is available under MIT License.

Check out the account-java-version branch for production code, the other branch "main" is not up to date yet.

Topics I'd love to discuss:

• Did I overcomplicate this? (ofc yes, totally, this is a technological showcase)
• Alternative approaches to real-time state sync
• Scaling WebSocket services beyond single instances
• When polyglot microservices are actually worth it

Documentation available:

• System architecture diagrams and sequence diagrams
• API documentation (Swagger/OpenAPI)
• Cloud Run configuration details
• WebSocket scalability proposals

Happy to answer questions about the journey, mistakes made, or architectural decisions!