How It Works

An interactive look at the architecture behind EPL Bets

Architecture Flows

Follow the live path, not just the parts

HTTP Request Flow

A tap turns into a Django view, an ORM read, and fresh HTML streamed right back into the page.

Starts Here
Browser
User action or HTMX event kicks off the request.
HTTP + HTMX
Server Render
Django
Views decide the response and prepare the template payload.
ORM Query
Source of Truth
PostgreSQL
Match, odds, and balance data are read safely from storage.
HTML Response
Visible Update
Back in the Browser
A full page or partial swaps into place without a SPA framework.

WebSocket Flow

The page stays subscribed while Redis and Channels push live score HTML back down the line.

Connected Client
Browser
The dashboard keeps a live socket open in the background.
WebSocket Connect
Real-Time Gateway
Daphne / Channels
Consumers fan updates out to every subscribed match or dashboard group.
Channel Layer
Broadcast Bus
Redis
Messages move through pub/sub so live score fragments can fan out fast.
OOB HTML Push
Instant Update
Browser Refreshes in Place
Scores and status chips update without the user ever reloading.

Celery Task Flow

Background jobs keep odds, fixtures, and live scores moving even when nobody is clicking.

Scheduled Work
Celery Worker
Beat schedules background tasks and workers pull them off Redis.
Fetch External Data
Outside the Stack
External APIs
football-data.org supplies fixtures and scores. Odds are generated algorithmically from standings data.
Persist Results
Stored State
PostgreSQL
Fresh data is written so the rest of the app can render from one source.
Queue + Broadcast
Message Core
Redis
Queues drive the workers and channel messages can trigger live UI updates.
Live Push to UI
Realtime Fan-Out
Daphne / Channels
If a match changed, subscribers receive the new HTML almost immediately.

Tap a glowing step in the flow to explore that part of the stack