Building Infrastructure for a National-Level CTF: Technical Lessons from RCS CTF 2026 The Challenge: Infrastructure for 100+ Hackers at Once January 30–31, 2026. The National-Level Capture the Flag competition at Lovely Professional University was about to start. Over 100 cybersecurity students from across India were about to connect to our platform simultaneously. And I was one of the infrastructure engineers responsible for keeping it running. Here's the problem: CTF platforms are brutally hard to host. 100+ concurrent users↓Real-time flag submissions↓Challenge-specific servers running exploitable code↓Network isolation requirements↓Scoring system needing instant updates↓Complete infrastructure failure = event cancelled We had zero room for error. This post covers the technical decisions we made, the disasters we prevented, and the lessons that apply to any high-stakes distributed system. Understanding CTF Infrastructure (What Most People Don't Know) Before diving into our setup, let me explain why CTF infrastructure is uniquely challenging. What is a CTF Platform? A CTF (Capture the Flag) competition is like a video game for hackers: Challenges are hosted on isolated serversEach challenge has a "flag" (a secret code)Participants exploit vulnerabilities to extract the flagFlag submission updates their score in real-timeScoring leaderboard is live and competitive Challenge Isolation:Challenge A might have a vulnerable PHP appChallenge B might have an exploitable Linux kernelIf Challenge A's vulnerability leaks to Challenge B's server, the entire competition is compromised Real-Time Constraints:Flag submission must update scores instantlyLeaderboard must reflect top 10 in less than 1 secondIf the scoring system lags, participants get frustrated and competition integrity collapses Scalability at Unknown Load:We didn't know how many teams would connectWe didn't know how many attacks would happen simultaneouslyBoth could spike unpredictably Security Under Attack:Participants are literally trying to break the systemA skilled hacker might try to hijack another team's session, modify the database, or crash serversWe had to defend against this while the competition is live Our Architecture: Designing for Chaos Here's the infrastructure stack we built: Internet↓Load Balancer (Cloudflare)↓API Gateway (Node.js + Express)↓Challenge Servers (Docker containers, isolated)Scoring Service (Redis + MongoDB)Leaderboard Service (Cached, updated every 5 seconds)Authentication Service (JWT + Sessions)↓Database (MongoDB, replicated) Let me break down each layer. Layer 1: Load Balancing (Cloudflare) Problem: 100 teams, each with 3–5 members, all hitting the platform simultaneously. A single server dies. What happens? Solution: Cloudflare sits in front of everything. User connects → Cloudflare (rate limiting, DDoS protection)→ Distributed to multiple API servers→ Requests balanced by health checks Rate limiting: 100 requests per minute per IPDDoS protection: Auto-block suspicious IPsGeographic routing: Users routed to nearest serverSSL/TLS: All traffic encrypted Why it matters: If one API server crashes, Cloudflare routes traffic to healthy servers. The competition keeps running. Layer 2: API Gateway (Node.js + Express) The brain of the platform. Every user action flows through here. Atomic transactions — Either all score updates happen or noneCache invalidation — Every flag submission refreshes leaderboard dataRate limiting per team — Prevent brute-forcing flags Layer 3: Challenge Servers (Dockerized, Isolated) Each challenge runs in its own Docker container on isolated networks. Isolation — One compromised challenge cannot affect othersEasy reset — Restart compromised containers instantlyResource limits — Prevent resource exhaustion attacksNetworking — Containers don’t talk to each other Real scenario: A competitor tried escaping a container. The exploit worked inside the container but couldn’t escape. That’s exactly what we wanted. Layer 4: Scoring Service (Redis + MongoDB) Real-time score updates go to MongoDB (persistent) and Redis (fast cache). MongoDB is the source of truthRedis is the speed layer Without cache: 1–2 secondsWith cache: less than 10ms Cache refresh every 5 seconds ensures speed with acceptable staleness. Real-Time Monitoring: Staying Awake for 48 Hours The competition ran continuously for 2 days. API Response TimeTarget: less than 500msAlert: more than 1000ms Error RatesTarget: less than 0.1%Alert: more than 1% Database Replication LagTarget: less than 100msAlert: more than 500ms Challenge Server HealthContainer runningAccessibleRespondingWithin resource limits If anything failed, we got alerts instantly. Disaster Scenarios (And How We Handled Them) Database CorruptionBug corrupted MongoDBFix: Replay last 5 minutes from logsLesson: Always design rollback systems Challenge Server CompromiseSQL injection attemptFix: Container isolation blocked itLesson: Isolation is critical DDoS Attack1000 flag submissions per secondFix: Rate limiter + Cloudflare blockLesson: Rate limiting is mandatory Memory LeakNode.js process slowed over timeFix: Restart at 80% memory usageLesson: Monitor memory continuously Lessons for Any High-Stakes System Isolate everythingCache aggressively, invalidate carefullyMonitor everythingRate limit everythingPlan for failuresKeep the team ready 100+ teams participated2 days continuous runtime0 major outagesLess than 5 seconds leaderboard update99.95% uptime The system worked flawlessly. If you’re building a similar system: Start with DockerAdd monitoring earlyDesign for failureRate limit aggressivelyCache smartly Infrastructure isn’t boring. It’s the backbone of every successful system. About This Experience As Infrastructure Lead for RCS CTF 2026, I learned that DevOps is about anticipating failures and building systems that survive them. GitHub: @anubhavxdevLinkedIn: @anubhavxdevPortfolio: anubhavjaiswal.meEmail: [email protected] Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or