Romish

• 01

  Everyone waits on someone

  Ten accepts, eight picks, six bans. Each step blocks on one person, so the flow has to move on by itself when they don't act.

• 02

  Anyone can vanish

  Players go AFK, close the tab or lose their connection at any point, and the match still needs a clean outcome.

• 03

  The server has to match the lobby

  A real CS2 server has to be started and configured for exactly those ten players on the chosen map, and then report the result back.

1. 01Solo or party

   Find Match

   • Queue solo or as a party of up to five. The party leader queues everyone.
   • Every member is checked before joining: bans, queue access, cooldowns and any other active session.
   • The Play button follows the player's state: Find Match, Ready Up, a cooldown countdown, or back to their match.

   Enlarge screenshot:

   

   Enlarge

2. 0225s

   Ready check

   • When ten players are found, everyone gets Accept or Decline and a 25-second countdown (admins can change it).
   • A decline or a no-show sends everyone who accepted back to the front of the queue, keeping their original wait time.
   • The timeout is resolved on the server, even if nobody has the page open.

   Enlarge screenshot:

   

   Enlarge

3. 0330s per pick

   Draft

   • Each party captains its own team through its highest-Elo member. With no parties, the two highest-Elo players captain.
   • Captains pick in the order A A B B A B A B. Party members are already placed on their team.
   • If a captain runs out of time, the server picks a random available player.

   Enlarge screenshot:

   

   Enlarge

4. 0420s per ban

   Veto

   • Captains take turns banning maps until one is left, and that map is played.
   • A missed turn bans a random map, so a captain who leaves can't stall the match.
   • The game server has been booting in the background since the match was created.

   Enlarge screenshot:

   

   Enlarge

5. 053 min cap

   Server setup

   • The platform starts the server, uploads a match config for these ten players and loads it, with no human involved.
   • Only the ten players see the connect details: the address, copy buttons and a steam:// link.
   • If setup fails twice or takes over 3 minutes, the match is cancelled with no penalties and all ten go back to the front of the queue.

   Enlarge screenshot:

   

   Enlarge

6. 06MatchZy

   Live

   • The MatchZy plugin runs the knife round, warmup, match and overtime on the game server.
   • The score updates round by round from a signed webhook, and anyone signed in can spectate.
   • A player who disconnects has 5 minutes to reconnect before it counts as an abandon.

   Enlarge screenshot:

   

   Enlarge

7. 07Elo applied

   Results

   • The results screen shows the winner, score, MVP, K/D/A and every player's Elo change.
   • Every player is released from the match at once, so Queue again works straight away.
   • The game server is stopped a minute later if no other match needs it.

   Enlarge screenshot:

   

   Enlarge

Enlarge screenshot:

Enlarge

Back to top

a.

Server-side timers

Timeouts are decided on the server, exactly once, whether or not anyone has the page open.

The problem

A match has eight kinds of deadline: ready checks, turns, setup and result timeouts, abandons, a live score poller and the server release. If browsers decided them, one closed tab could freeze a match and two open tabs could fire the same timeout twice.

Show what I built and why it holds up

What I built

• Every deadline lives in one Redis sorted set: the member is the task, the score is when it is due. Scheduling the same task again just moves its deadline.
• A Lua script reads the due tasks and removes them in one step, so each task goes to exactly one caller, however many instances are sweeping.
• On a long-running server, a sweeper runs every 2 seconds, holding a short Redis lease so only one instance sweeps at a time.
• On serverless hosting, scheduling a deadline also publishes a delayed QStash message that wakes a signed endpoint one second after it is due.

Why it holds up

• An early, duplicate or stale wake-up finds nothing to do, because the Redis set is the source of truth.
• A task that throws is rescheduled 10 seconds later instead of being lost.
• Handlers re-check state before acting. An auto-pick is a conditional write on the pick index, so it lands once even if the sweeper and several open pages report the same timeout.

Show the scheduler pseudocode

schedule(task, dueAt):
  ZADD deadlines dueAt task        # same task again = new deadline
  if serverless:
    qstash.publish("/api/cron/match-tick", delay = dueAt - now + 1s)

sweep():                           # every 2s, or on a QStash wake-up
  tasks = EVAL takeDue(now)        # Lua: read due members + remove them, atomically
  for task in tasks:
    try:   run(task)               # re-checks the match before acting
    catch: schedule(task, now + 10s)

b.

One active session per player

A player can only be in one flow at a time, and a stale lock can never trap them.

The problem

A double click, two tabs, or a party leader queueing while a member joins somewhere else could put one player in two matches. Nine people waiting on someone who is busy elsewhere is a dead match.

Show what I built and why it holds up

What I built

• Each player has a session record in Redis: what they are in (queue, ready check or match), the phase, and its deadline.
• Joining the queue claims the lock for the whole unit, solo or party, in one Lua call. Either every member gets it or nobody does.
• Every way into a flow refuses a player who is already in one, and names who is blocking ("Viper is currently in a match").
• One browser tab drives the session. Other tabs can watch, and show "Session active in another window" with a Use this tab button.

Why it holds up

• Reads heal the lock. Every read checks it against the queue, the ready check and the match: a lock whose match is over is released on the spot, and a player who is really in a match gets their lock back.
• Every way out (result, forfeit, any cancel) goes through one release function, so no path forgets a player.
• Refreshing, bookmarking or typing a URL lands on the real phase page through server-side redirects.

Show the session lock pseudocode

claimSessions(members, session):   # one Lua script: all or nothing
  for m in members:
    if EXISTS session:{m}: return CONFLICT(m)
  for m in members:
    SET session:{m} session EX safetyTtl
  return OK

readSession(user):                  # every read reconciles
  lock  = GET session:{user}
  truth = queued(user) or readyCheck(user) or liveMatch(user)
  if lock and not truth: DEL session:{user}      # match over: free them
  if truth and not lock: SET session:{user} ...   # really playing: restore

c.

Automating the game server

From the last ban to a configured CS2 server with no human involved, and a clean exit if it fails.

The problem

Before anyone can play, a real CS2 server has to be running, locked to exactly these ten players, on the map the veto chose, and able to report the result back. Every one of those steps can fail.

Show what I built and why it holds up

What I built

• Start early. The DatHost server is started when the match is created, so it has usually booted by the last ban. Setup checks again and waits for the boot if needed.
• Configure. The app builds a MatchZy match config (teams, Steam IDs, map, a knife round for sides) and a whitelist of the ten Steam IDs, and uploads them over FTP.
• Load. It runs the config over RCON, reads the server address, and flips the match to live only if it is still in setup, with a conditional update.
• Report back. MatchZy posts going live, every round, disconnects and the final result to a webhook that checks a shared secret in constant time.

Why it holds up

• One automatic retry after 5 seconds, and a 3-minute cap on the whole setup.
• If it still fails, the match is cancelled with no penalty for anyone, and all ten players go back to the front of the queue.
• A setup that finishes after its match was cancelled never goes live. The server is released instead.
• Finishing a match is idempotent. MatchZy can send both of its end-of-match events and Elo is still applied once.

Show the MatchZy match config

{
  "matchid": 1042,
  "team1": { "name": "<alpha captain>", "players": { "<steam64>": "<name>" } },
  "team2": { "name": "<beta captain>",  "players": { "<steam64>": "<name>" } },
  "num_maps": 1,
  "maplist": ["de_mirage"],
  "map_sides": ["knife"],
  "players_per_team": 5,
  "cvars": {
    "matchzy_remote_log_url": "<app>/api/webhooks/matchzy",
    "matchzy_remote_log_header_key": "X-MatchZy-Secret"
  }
}

Enlarge screenshot:

Enlarge

d.

Fair play

Rules that punish bad behaviour, not bad luck.

The problem

Teams have to be balanced and captains chosen fairly, and players who dodge or abandon need a consequence. None of that should punish anyone for the platform's own failures.

Show what I built and why it holds up

What I built

• Matchmaking takes the oldest waiting group first. A party is taken whole or not at all and never larger than one team, with an optional cap on the Elo spread. It is a pure, unit-tested function shared with the admin Match Lab.
• Captains: each party goes on one team and its highest-Elo member captains it. Otherwise the two highest-Elo solo players captain.
• Elo: each side's rating is its team average, K = 32, and every player on a side gets that side's change, so the result is zero-sum.
• Cooldowns and Trust Score escalate within a rolling 24 hours. Admins can lift a cooldown, and the offense still counts toward the next one.

Why it holds up

• Server setup failures, admin cancels and missing results never penalise anyone.
• Each player is penalised at most once per match.
• Every timer, cooldown and penalty number lives in one rules file.

Penalties within a rolling 24 hours. Trust Score starts at 100 and never drops below 0.

Offense	Queue cooldown (1st, 2nd, 3rd and later)	Trust Score
Decline a ready check	5 min, 15 min, 1 h	No change
Miss a ready check	5 min, 15 min, 1 h	No change
Abandon after accepting	5 min, 15 min, 1 h	-5, -10, -20
Captain turn timeout	None	-5 each, from the 3rd

Penalties within a rolling 24 hours. Trust Score starts at 100 and never drops below 0.

• Decline a ready check

  Queue cooldown (1st, 2nd, 3rd and later)

  5 min, 15 min, 1 h

  Trust Score

  No change

• Miss a ready check

  Queue cooldown (1st, 2nd, 3rd and later)

  5 min, 15 min, 1 h

  Trust Score

  No change

• Abandon after accepting

  Queue cooldown (1st, 2nd, 3rd and later)

  5 min, 15 min, 1 h

  Trust Score

  -5, -10, -20

• Captain turn timeout

  Queue cooldown (1st, 2nd, 3rd and later)

  None

  Trust Score

  -5 each, from the 3rd

Show the Elo calculation

ratingA   = average(team A Elo)
ratingB   = average(team B Elo)
expectedA = 1 / (1 + 10 ^ ((ratingB - ratingA) / 400))
changeA   = round(32 * (resultA - expectedA))   # resultA: 1 win, 0 loss
changeB   = -changeA                           # zero-sum: team B mirrors it

Enlarge screenshot:

Enlarge

e.

Realtime and privacy

Everyone sees the same state instantly, and nobody sees what they shouldn't.

The problem

Ten players, spectators and admins all watch the same match. Picks and bans have to appear instantly, but connect details, party chat and direct messages must only reach the right people.

Show what I built and why it holds up

What I built

• Pusher channels are split by audience: public channels carry only public state, private channels carry per-user, party and team data, and a presence channel runs global chat.
• The server authorises private channels by checking membership (your own user channel, your party, your team in this match) and the CSRF token.
• The browser keeps one subscription per channel, however many components listen to it.
• Spectators get an allow-list of match fields. Any field added to the model later stays hidden until it is listed.

Why it holds up

• No public event carries connect details, IPs or passwords. When the server is ready, players refetch the match, and only the ten players get the address back.
• Draft, veto and server setup can't be spectated at all.
• Pages resync on focus, on reconnect and on a slow poll, so a dropped connection never leaves a stale screen. Clocks use the server's time, so a refresh shows the same number.

Pusher channels by audience.

Channel	Type	Carries
queue, match-{id}, live-matches	Public	Queue changes, picks, bans and scores. Never private data.
private-user-{id}	Private	Session updates, party, friends, notifications and DMs
private-party-{id}, private-team-{match}-{side}	Private	Party chat and team chat
presence-global-chat	Presence	Global chat, with who's online

Pusher channels by audience.

• queue, match-{id}, live-matches

  Type

  Public

  Carries

  Queue changes, picks, bans and scores. Never private data.

• private-user-{id}

  Type

  Private

  Carries

  Session updates, party, friends, notifications and DMs

• private-party-{id}, private-team-{match}-{side}

  Type

  Private

  Carries

  Party chat and team chat

• presence-global-chat

  Type

  Presence

  Carries

  Global chat, with who's online

f.

Security

Every way into the app is checked: browsers, game servers, payments and the scheduler.

The problem

The app takes requests from browsers and from four machine callers (the game server, DatHost, Stripe and QStash), and it has an admin panel that can ban players and power a real game server.

Show what I built and why it holds up

What I built

• A proxy runs before every request. It applies rate limits (stricter on login and queue join, plus per-action limits on invites, friend requests and chat) and checks a CSRF double-submit token on every mutating API call.
• Webhooks skip CSRF and prove who they are instead: MatchZy with a shared secret compared in constant time, DatHost with an HMAC, Stripe with its signature, and QStash with a signed JWT that supports key rotation.
• Steam sign-in is verified server-side with Steam. Sessions are stored in the database behind a host-only, HttpOnly cookie.
• Security headers: a Content Security Policy, X-Frame-Options DENY, nosniff, and strict referrer and permissions policies.
• Admin routes are gated by role (moderator, admin, owner), and every admin change is written to an audit log. Config changes are stored as a before and after diff.

Why it holds up

• Request bodies are validated with Zod.
• User input in database search queries is escaped.
• Blocks are never revealed: a blocked player's card just returns "not found".

Back to top

Back to top

Back to top

• Social

  • Friends with live presence (online, in queue, in party, in match). One record per pair, so one-sided states are impossible.
  • Parties of up to five, with invites by name search, from friends, or through a 15-minute invite link.
  • Chat in four channel types (global, party, team and DMs) with unread badges, edits, reports, slow mode and a profanity filter.
  • Notifications with toasts and inline actions that clear in every tab once acted on.

• Admin panel

  • Moderation: reports with evidence, bans, chat mutes and player notes.
  • Live config without a deploy: queue rules, party size, ready-check time, maintenance mode and the site banner, pushed to open tabs.
  • Analytics: player, matchmaking and server charts, retention cohorts and the Elo distribution.
  • Every admin action recorded in an audit log.

• Billing

  • Stripe Checkout for three monthly tiers.
  • A signed Stripe webhook activates, renews and cancels subscriptions, and players can cancel themselves.
  • Admins can grant access by hand, and an open beta switch lets everyone queue.

Enlarge screenshot:

Enlarge

Enlarge screenshot:

Enlarge

Back to top

Before and after

Before

Enlarge screenshot:

Enlarge

After

Screenshot coming soon

Play page, after

Back to top

Jest unit and API tests

The pure rules (matchmaker, Elo, draft and veto), the session lock, scheduler, penalties, server setup and spectator privacy, plus route handlers for the queue, matches, sessions and admin role gates.

A fake Redis that runs the real Lua

An in-memory stand-in for Upstash with strings, sets, sorted sets, hashes, pipelines and the app's own Lua scripts, so the atomic claims are tested as written.

Bot scripts

Scripts that act as seeded test users and play through the flow. The failure-path script runs 40 checks: ready-check timeouts, declines, setup failure and requeue, captain timeouts, two admins cancelling at once, and spectator privacy. It fast-forwards deadlines through the production code, so it never waits on real clocks.

CI on every push

GitHub Actions runs lint, the type-check, npm audit, Jest with coverage, a Playwright smoke set and a production build.

Match Lab and UI Studio

Admin tools that run each match stage in a sandbox against fake players using the production rule functions, and render every real screen with simulated data, each state reachable by URL.

Enlarge screenshot:

Enlarge

Back to top

1. 01

   One definition for the session cookie

   Cookie settings drifted apart between NextAuth, the Steam login route and the user endpoint, and logins failed silently: players signed in, then looked signed out on the next page. Now all three read one shared definition.

2. 02

   Don't log players out everywhere

   Deleting other sessions on login looked like good hygiene, but it signed players out on every other device. I removed it and left a comment in the code so it does not come back.

3. 03

   Load images in batches

   Loading a dozen large map images at once caused connection resets in development. Map grids now load in small, staggered batches.

4. 04

   Let the server own the clock

   When timers ran in the browser, what happened at a deadline depended on who had the page open. Moving every deadline to the server made outcomes the same whether or not anyone is watching.

The full match flow is built and covered by tests and bot scripts. Before opening it up, I am working on:

• Map pools set from the admin panel and used in every veto
• A priority queue for paid tiers
• Complete GDPR data export and account deletion
• Tournaments