PitchPulse26 — A production World Cup prediction platform, end‑to‑end.

Build a complete prediction platform that real users can sign up for, predict on, and trust to lock at kickoff — not a demo, not a toy. That meant owning every layer: a typed React frontend, a Node API with proper auth and validation, a relational schema that survives result updates, infrastructure as code, a real CI/CD pipeline, and the monitoring and rollback path required to operate it.

The strongest proof that this is a real product is that the core user flows are visible in the UI: making predictions, tracking personal progress, setting official results as an admin, and seeing scored outcomes reflected on the leaderboard.

Matches Workflow

Admin Result Entry

Leaderboard Feedback Loop

The runtime is fully serverless on AWS. The React + TypeScript client is delivered through AWS Amplify; the API is a Node + Express app fronted by API Gateway and executed on Lambda; data lives in a serverless PostgreSQL database on Neon, accessed via Prisma using the @prisma/adapter-neon driver over WebSocket so cold starts stay cheap.

The custom domain was purchased through Namecheap, while DNS is managed in Route 53 through a hosted zone that points the public frontend domain to Amplify.

CloudWatch holds dashboards, alarms, and structured logs. SSM Parameter Store provides runtime configuration. GitHub Actions handles CI/CD, while Amplify deploys the frontend from the `main` branch and the backend deploy workflow packages and updates Lambda.

GitHub Actions builds, tests, packages, and deploys on every push to main. The backend workflow runs tests, packages a Lambda artifact, uploads it to S3, updates Lambda, and verifies the deployment with a health check. Frontend delivery is handled through Amplify Git integration.

The Lambda artifact is uploaded to S3 with a versioned key so rollback is just a redeploy of the previous artifact — no rebuild required.

CloudWatch is the source of truth in production. The dashboard and alarms are managed by Terraform under infra/monitoring.tf so the alerting story ships with the infrastructure, not after it.

Dashboard — pitchpulse26-prod-overview

• Lambda Invocations
• Lambda Errors
• Lambda Duration
• API Gateway 4xx
• API Gateway 5xx
• API Gateway Count

Alarms

• pitchpulse26-lambda-errors — fires on any unhandled Lambda exceptions during a rolling window.
• pitchpulse26-api-5xx — fires on API Gateway 5xx responses, the user-visible failure mode.
• pitchpulse26-lambda-duration-high — catches latency regressions before users do.

Log Groups — 14 day retention

• /aws/lambda/pitchpulse26-api
• /aws/apigateway/pitchpulse26

Production Monitoring

Production incidents need a known-good escape hatch. The rollback runbook lives in the repo at docs/runbooks/deployment-rollback.md and follows three rules:

• Frontend: roll back through Amplify deployment history, or revert the bad commit on main and let CI redeploy.
• Backend: redeploy the last known-good Lambda artifact from S3. No rebuild.
• Database: avoid DB rollback entirely by keeping migrations backward-compatible. Code rollback alone is enough.

Alarms without runbooks generate noise, not action. This one is written before the alarm fires, not after.

• JWT authentication, 1-day expiry, secret loaded from environment.
• Passwords hashed with bcrypt (cost 10).
• Role-based access control: user and admin; admin endpoints gate result-setting.
• Email verification gating — unverified users cannot submit predictions.
• Zod input validation on every endpoint; Helmet for HTTP security headers; CORS restricted to the configured origin.
• Rate limiting on auth endpoints (20 requests / 15 minutes) and a 10kb request body cap to blunt abuse.
• Prediction lockout enforced at API and UI layers after kickoff.

The goal is not to claim production scale that does not exist; the goal is to operate against explicit targets I would defend in a review.

Lambda error rate

< 1%

alarm trips above this

API 5xx rate

< 0.5%

user-visible failures

Time to rollback

< 5 min

via S3-archived Lambda artifact

Log retention

14 days

cost / compliance lever

Cold-start budget

< 1.5s p95

Neon WS adapter assumed

Predictions / match

1 per user

enforced by unique constraint

• Add canary deploys via Lambda alias weighting (10% → 100%) so deploys are revertible without a redeploy.
• Refactor the Matches page to reduce orchestration complexity and split critical data loads from secondary UI context.
• Move to RDS Proxy or pgBouncer if concurrent prediction load starts to saturate Neon connections during a kickoff window.
• Add Sentry on the client to catch frontend errors I currently do not see in CloudWatch.
• Author a k6 load test that hits /api/matches and /api/predictions under realistic match-window load and capture p95 latency alongside cold-start rate.