The problem

A cricket simulation needs plausible outcomes and consistent match state. Concurrent requests must not apply the same delivery twice or leave different clients looking at different games.

The approach

  1. Model ball outcomes using match phase, momentum, and pressure. Send live state changes over WebSockets.
  2. Build a modular Flask REST API backed by a 13-model SQLAlchemy schema with indexed queries and cascade deletes.
  3. Use per-match threading locks and a single-worker, multi-thread Gunicorn deployment to keep in-memory state coherent. Operate it on OCI behind Nginx.

How it fits together

Match state
Probability engine
Delivery outcome
State update
WebSocket clients

The result

Served 13,000 active users and resolved a 120-delivery match in under five seconds.

The engineering decision

A single worker simplifies shared match-state correctness. Per-match locks protect updates, at the cost of limiting scale to that process until state is moved behind a shared coordination layer.