Skip to content

Infrastructure handbook

This is the entry point for how BigBash runs in the cloud. Config (CIDRs, replica counts, image tags, Terraform variables) lives in four GitHub repos. This site explains. If a number here and Terraform disagree, Terraform wins — then update this page.

Never paste secrets, passwords, or full Helm values here.

New here? Read this page, then the Visual map (three flows), then Where to change. Interactive pictures: C4 workspace.

What the system is

BigBash is a sports-betting product (customer site + operator admin). FalconX is the engineering name for the same platform. Folders named fantasy7-* in GitOps are historical; they mean BigBash.

Bettors use the B2C site. Operators use the B2B admin. APIs sit behind a gateway hostname. Odds and catalogue also come from Betfair and other third-party feeds.

Where it runs

PlaceWhat it is
localDocker Compose on a laptop (Local-dev-setup) — same services, not AWS
isolatedCI end-to-end compose with pre-built images
developShared cloud. AWS account 460195068944, region eu-west-2 (London). Cluster rfe-dev-cluster, namespace development. Hosts on *.bigbash.life
perfLoad tests. Same account and cluster as develop, namespace performance. Own Valkey, Debezium, CloudFront, ECR. Shares Aurora and Kafka with develop
prodLive traffic. Separate account 389068786427, cluster rfe-prod-cluster, namespace production. Hosts on bigbash.site

WAF and CloudFront certificates live in us-east-1 because CloudFront requires that. Everything else is eu-west-2.

How we manage infrastructure

We do not click AWS consoles as the source of truth.

LayerRepositoryJob
Recipestf-modulesHow a VPC / Aurora / MSK cluster is built
This environmentrfetech-infraSizes, topics, accounts, EKS seed, CloudFront
Desired cluster staterfetech-gitopsTraefik, Groundcover, Helm values, image tags
Pipelinesrfetech-github-actionsScan, build, push to ECR, bump GitOps

Amazon Elastic Kubernetes Service (EKS) runs the apps. Argo CD makes the cluster match git. CI never kubectl applys product apps.

Detail: Four repos · Creating things

Main components (why they exist)

PieceWhy
CloudFront + WAFPublic HTTPS, caching, rate limits. Pods stay private
Traefik (internal NLB)In-cluster ingress. CloudFront VPC origin. Gateway API HTTPRoutes
EKS + KarpenterRun containers. Nodes appear when pods need CPU; Auto Mode + NodePools
Aurora PostgreSQLSystem of record (one cluster, database per service). Second cluster for Data Aggregator
Valkey (ElastiCache)Redis-compatible cache / pub-sub / sessions
MSK (Kafka) + DebeziumAsync events. Outbox CDC so consumers do not poll OLTP
Secrets Manager + CSIOne config blob per env; pods mount it. No passwords in Helm
ECRContainer images {service}-{develop|perf|prod}
Groundcover + SentryTraces/logs/APM and product errors
SSM bastionBreak-glass to databases — no public DB ports

If a piece fails: CloudFront/WAF → users cannot enter. Traefik → 502s. EKS/Karpenter → no capacity. Aurora → writes fail. Valkey → cache/odds degrade. MSK/Debezium → async lag, OLTP still up. Argo CD down → deploys stop, running pods keep serving.

Four flows

Hop-by-hop (request, ship, outbox CDC): Visual map. Infra PRs: Changes.

How to read this handbook

I need…Page
Pictures of every flowVisual map
Interactive C4C4
Develop vs perf vs prodEnvironments
VPC, CloudFront, bastionNetworking
EKS, Karpenter, nodesKubernetes
Image tags, Argo, LambdasCompute & deploy
Aurora, Valkey, Kafka, CDCData stores
IAM, CSI, secret namesIAM & secrets
Betfair and other vendorsDependencies
Metrics, logs, alertsObservability
“Which file do I edit?”Changes
Something is on fireTroubleshooting
Laptop composeLocal stack

Production vs not

  • Prod is a separate AWS account, VPC, EKS cluster, Aurora, MSK, Valkey, CloudFront on bigbash.site. HPA is on. Prod GitOps PRs require infra-team.
  • Develop is the shared integration cluster. ApplicationSet forces HPA/KEDA/PDBs off.
  • Perf is not a copy of prod. It is a namespace plus overlays on develop’s VPC/cluster/Aurora/MSK.

Rules

  1. Narrative here; configuration in the four repos.
  2. Architecture decision: ADR here first, then implement.
  3. Do not kubectl apply product workloads as the happy path.

BigBash architecture SSOT — hosted for the team; edit via pull requests.