Here's my architecture 🙂

The user starts at "/", where they enter a login. The Players GenServer checks this login for uniqueness.

Using JavaScript, I save the login in the browser's sessionStorage and make an HTTP request to "/sync", where the controller saves it to the server session.

Next is "/lobby", which is protected by the :protected pipeline. Users must have a valid server session to access it—otherwise, they're redirected back to "/".

The LobbiesManager is a GenServer that manages information not related to the game state.

Then there's "/lobby/:id/:role", which is protected by both the :protected and :require_lobby_access pipelines.

These pipelines check whether the user has permission to access the specific lobby.

Each time a lobby is created, a DynamicSupervisor starts a new LobbyServer process. Lobbies with the same ID share one LobbyServer instance.

The LobbyServer holds the game state and player rankings. It's also connected to a Timer, which manages the game logic.

What i would change

If I could start this project over, I'd focus more on the overall architecture. Right now, there's unused data in modules like Players and LobbiesManager. I'm also considering moving passwords and scores into a separate module to make the structure cleaner and more modular.

Another improvement would be implementing a continuous game flow so the host wouldn't need to manually rearrange pairs or click "Start" each round. I would implement the same logic we discussed during the interview — the game engine will be built on a linked list, where each event triggers the next one, and this event is added to the beginning of the list. Actually, I think I’ll build this next week anyway:)

After gaining some basic knowledge of Elixir and LiveView, I'd go deeper and start using ETS and Presence for better state management and scalability.

And probably the most annoying issue—I couldn't fix a checkbox bug where they only appear checked on the second click. Would you be able to give me some advice on that?