Capstone Brief — Design a Production-Ready Cricket Analytics Platform

Your Capstone Project

You have completed five modules covering Linux, Bash scripting, networking, AWS core services and multi-cloud fundamentals. Now you will apply everything by designing and implementing a production-ready cricket analytics platform from scratch. This capstone project mirrors real-world cloud engineering work — you will make architectural decisions, justify trade-offs, provision infrastructure using code, secure the deployment following cloud security best practices, and add observability so you can monitor and debug the platform in production. The deliverable is a working platform with documented architecture decisions.

Analogy🏏Cricket

🏏 Think of it like cricket: This capstone is your debut Test match — not a practice session or a warm-up game, but the real tournament where everything you have learned is tested simultaneously. You are not just executing drills (individual lessons); you are combining batting (compute), fielding (networking), bowling (databases) and strategy (architecture) into a cohesive match performance. A Test cricketer who can bat well in isolation but cannot construct a match-winning innings (build a complete production system) has not yet demonstrated the skill needed at the highest level. This capstone is that innings.

Project Specification

You will design and build a Cricket Analytics Platform for SkillVeris that ingests live match data, stores it in a structured database, serves an API for fan applications, and provides analytical dashboards for cricket statisticians. The platform must handle IPL match-day traffic of 10,000 concurrent API requests per second without manual scaling, recover automatically from single availability zone failures, store match data durably with point-in-time recovery, implement least-privilege IAM with no hardcoded credentials, and provide operational visibility through logs, metrics and alerts. The platform is deployed using infrastructure-as-code with a documented runbook for on-call engineers.

Functional Requirements

Data Ingestion: Accept ball-by-ball match data via S3 upload (CSV or JSON), automatically processed by a Lambda function within 30 seconds of upload.
Data Storage: Store all match deliveries in DynamoDB (real-time queries) and a PostgreSQL analytics database (complex historical queries). Retain data for 7 years with automated backups.
API: REST API served via ALB and EC2 Auto Scaling Group, returning match scores and player statistics in under 200ms at p99. Endpoints: GET /matches, GET /match/{id}, GET /player/{id}/stats.
Fan Traffic: The API must handle 10,000 requests/second during IPL finals without pre-provisioning. Auto Scaling with target tracking at 60% CPU utilisation.
Analytics: A scheduled Lambda function runs nightly SQL queries against PostgreSQL and stores aggregated statistics in S3 for dashboard consumption.
Multi-Region DNS: Route 53 latency routing between ap-south-1 (Mumbai) and ap-southeast-1 (Singapore) with health-check-based failover.

Non-Functional Requirements

Security: No hardcoded credentials anywhere. IAM roles for all AWS services. All data encrypted at rest (KMS) and in transit (TLS 1.2+). S3 Block Public Access enabled. VPC with private subnets for databases and application tier.
Availability: 99.9% uptime SLA. Multi-AZ RDS and DynamoDB. ALB distributes across 3 AZs. Route 53 health checks with failover to secondary region in under 90 seconds.
Observability: CloudWatch dashboards showing API latency, error rate, DB connection count and Lambda duration. Alarms on 5xx error rate over 1% and p99 latency over 500ms. Structured JSON application logs.
Infrastructure-as-Code: All resources provisioned with Terraform. Version-controlled in Git. README with architecture diagram and deployment instructions.
Cost: Monthly cost estimate provided. Reserved Instances or Savings Plans applied where appropriate. Auto Scaling configured to scale in during off-peak hours.

Architecture Diagram Requirements

Your architecture documentation must include a diagram showing the three-tier VPC (public, application, data subnets across 3 AZs), the data ingestion pipeline (S3 → Lambda → DynamoDB + RDS), the API serving path (Route 53 → ALB → EC2 ASG → RDS + DynamoDB), the analytics pipeline (CloudWatch Events → Lambda → S3 → Dashboard), and the security boundaries (IAM roles, security groups, VPC endpoints). The diagram should clearly show which resources are in which subnet tier, which security groups are applied, and the data flow between components. Draw this diagram using draw.io, Lucidchart or ASCII art — the medium is less important than the clarity of the architectural thinking.

Deliverables

Architecture Decision Record (ADR): A document explaining why you chose each major service (DynamoDB vs RDS for operational queries, EC2 ASG vs ECS Fargate for the API, etc.) with alternatives considered and trade-offs.
Terraform code: Complete IaC for all AWS resources — VPC, subnets, security groups, IAM roles, RDS, DynamoDB, S3, Lambda, ALB, ASG and Route 53 records.
Lambda function code: The data ingestion processor (Python) with unit tests and error handling.
CloudWatch dashboard: JSON definition for the operational dashboard exportable from AWS console.
Runbook: Markdown document with procedures for common operations — deploying a new version, responding to high error rate alarm, restoring from RDS backup, and manual scale-out.

Evaluation Criteria

Your capstone will be evaluated across five dimensions. Architecture quality: Does the design handle the stated load? Is the failure domain reasoning correct? Are services chosen appropriately for each workload? Security posture: Are all the IAM policies least-privilege? Is there any hardcoded credential? Are all network paths appropriately restricted? Operational readiness: Can an on-call engineer use the runbook to respond to an incident? Do the CloudWatch alarms cover the most likely failure modes? Code quality: Is the Terraform code modular and parameterised? Is the Lambda function testable and readable? Documentation quality: Is the architecture diagram accurate? Are the trade-offs well-reasoned in the ADR? Use the next three M6 lessons to build and refine each component of this capstone.