pshenok/server-survival: Learn Cloud Architecture by Playing Tower Defense

pshenok/server-survival: Learn Cloud Architecture by Playing Tower Defense

Cloud architecture is hard to learn from documentation alone. You can read about load balancers, auto-scaling groups, and DDoS mitigation, but until you've felt the pressure of traffic spiking 4× in three minutes while your database chokes and your budget bleeds, the lessons don't stick. pshenok/server-survival bridges that gap. It's an interactive 3D simulation where you play as a Cloud Architect, building infrastructure to survive escalating traffic waves, malicious attacks, and economic constraints — all in real time.

This open-source tower defense game (6,151 GitHub stars, 690 forks, MIT licensed) runs entirely in your browser using vanilla JavaScript^{↗ Bright Coding Blog} and Three.js. No AWS^{↗ Bright Coding Blog} account required. No surprise bills. Just immediate, visceral feedback on whether your architecture decisions hold up under pressure.

What is pshenok/server-survival?

pshenok/server-survival is a browser-based 3D tower defense game created by developer pshenok. Built with vanilla JavaScript (ES6+), Three.js for rendering, and Tailwind CSS^{↗ Bright Coding Blog} for its glassmorphism UI, it requires zero build step — you open index.html and play. The last commit was July 14, 2026, indicating active maintenance.

The game belongs to a growing category of educational infrastructure simulators: tools that gamify systems concepts traditionally taught through certification courses or painful production incidents. Unlike static labs or cloud provider sandboxes, pshenok/server-survival imposes real-time consequences. Your services degrade under load. Your budget drains from over-provisioning. Your reputation crashes when DDoS traffic leaks past a missing firewall.

The core loop mirrors actual cloud engineering: process legitimate traffic to earn money, spend that money on infrastructure, scale ahead of demand spikes, and survive random events (cost spikes, capacity drops, traffic pattern shifts) that occur every 15–45 seconds. The game ends when reputation hits 0% or you hit $-1,000 bankruptcy.

Two modes serve different learning needs. Survival Mode is the pressured, escalating challenge. Sandbox Mode removes failure states and gives full control over budget, RPS, traffic mix, and burst patterns — ideal for testing specific architectures or teaching concepts without time pressure.

Key Features

Realistic Traffic Taxonomy

The game models six traffic types with distinct behaviors, rewards, and routing requirements. Static requests (green) hit CDN/Storage. READ operations (blue) prefer replicas and NoSQL. WRITE operations (orange) need database persistence. UPLOAD (yellow) goes to Storage. SEARCH (cyan) routes to Search Engine or SQL DB fallback. MALICIOUS traffic (red) must be blocked at the firewall. Each type has specific dollar rewards and reputation impacts, creating genuine trade-offs in architecture design.

Tiered, Upgradeable Services

Fourteen infrastructure components span security (Firewall), networking (API Gateway, Load Balancer), compute (Compute, Serverless Function), storage (CDN, Storage), databases (SQL DB, NoSQL DB, Read Replica, Search Engine), and caching (Cache). Most core services upgrade from Tier 1 to Tier 3, scaling capacity and performance. The Serverless Function, added in v2.3, introduces pay-per-use economics: $45 placement, $2/min upkeep, plus $0.03 per completed request — cheap at idle, expensive under sustained load.

Dynamic Degradation & Repair

Services lose health under load and require manual or auto-repair (with 10% upkeep overhead). Damaged services operate at reduced capacity. Repair costs 15% of service cost. This forces active management rather than fire-and-forget placement.

Contextual Smart Hints

The game surfaces architecture suggestions based on observed bottlenecks: "DB overloaded with SEARCH — add a Search Engine!" or warnings when Serverless per-request costs exceed Compute economics at high RPS.

Economic & Reputation Systems

Success requires balancing income (per-request rewards) against upkeep costs that scale 1× to 2× over 10 minutes. Throttled requests (via API Gateway) cost only -0.2 reputation versus -1.0 for hard failures, enabling graceful degradation strategies.

Use Cases

Onboarding Junior Engineers to Cloud Concepts

New team members can experiment with CDN caching, database read replicas, and queue-based load leveling without risking production infrastructure or cloud budgets. The visual, real-time feedback accelerates intuition for concepts that typically require months of incident exposure.

Interview Preparation & Architecture Discussions

Sandbox Mode enables rapid prototyping of architecture patterns: "How does a Queue + Compute + Cache stack perform under 55% SEARCH traffic?" Candidates can demonstrate reasoning through concrete simulation rather than whiteboard abstraction.

Teaching Load Balancing & Auto-Scaling Trade-offs

The Serverless Function versus Compute comparison directly illustrates when pay-per-use beats provisioned capacity. Instructors can set specific RPS and traffic mix, then have students optimize for cost or performance under constraints.

Team Training for Incident Response

Survival Mode's random events (DDoS spikes, cost spikes, traffic bursts every 15–45 seconds) simulate production pressure. Teams can practice rapid diagnosis and mitigation in compressed timeframes with visible consequences.

Validating Architecture Patterns Before Cloud Deployment

While not a substitute for load testing, pshenok/server-survival validates conceptual understanding: Will your proposed caching layer actually reduce database load? Does your queue depth handle burst patterns? The simulation catches logical gaps before they become expensive cloud configurations.

Installation & Setup

The project requires no build tooling. Setup is intentionally minimal:

# Clone the repository
git clone https://github.com/pshenok/server-survival.git

# Navigate to project directory
cd server-survival

# Open index.html in your modern web browser
# On macOS:
open index.html

# On Linux:
xdg-open index.html

# On Windows:
start index.html

Alternatively, serve via any static file server for broader compatibility:

# Using Python↗ Bright Coding Blog 3
python -m http.server 8000

# Using Node.js npx
npx serve .

# Using PHP↗ Bright Coding Blog
php -S localhost:8000

Then navigate to http://localhost:8000. The game loads entirely client-side; no backend or API keys required.

For immediate play without cloning, the hosted version is available at https://pshenok.github.io/server-survival/.

Real Code Examples

The project ships as standard HTML/CSS/JS with no build step. The structure follows conventional static web patterns. While the README does not contain extensive inline code samples, the documented architecture reveals key implementation patterns.

Service Definition Pattern

Services are defined with structured cost/capacity/upkeep metadata, as shown in the README's infrastructure table. This data drives both gameplay balance and UI rendering:

// Conceptual structure based on documented service definitions
// Each service follows this schema for game balance
const serviceSchema = {
  firewall: {
    cost: 40,
    capacity: 30,
    upkeep: 'low',
    function: 'security', // Blocks malicious traffic
    upgradeable: false
  },
  compute: {
    cost: 60,
    capacity: 4,
    upkeep: 'high',
    function: 'processing',
    upgradeable: true,    // T1 → T3
    tiers: [4, 8, 16]     // Capacity per tier
  },
  serverlessFunction: {
    cost: 45,
    capacity: 30,         // Auto-scales
    upkeep: 'very_low',
    perRequestCost: 0.03, // $/request
    coldStartMs: 900,
    function: 'pay-per-use compute'
  }
};

Routing Topology Validation

The README documents strict connection rules that the game enforces. This topology validation is central to teaching correct architecture patterns:

// Valid flow directions per README documentation
const validFlows = {
  internet: ['firewall', 'cdn', 'apiGateway'],
  firewall: ['loadBalancer'],
  cdn: ['storage'],           // 95% static hit rate
  apiGateway: ['loadBalancer'],
  loadBalancer: ['queue', 'compute', 'serverlessFunction'],
  queue: ['compute', 'serverlessFunction'],
  compute: ['cache', 'searchEngine', 'readReplica', 'sqlDb', 'nosqlDb', 'storage'],
  serverlessFunction: ['cache', 'searchEngine', 'readReplica', 'sqlDb', 'nosqlDb', 'storage'],
  cache: ['sqlDb', 'nosqlDb'], // Reduces DB load
  // Terminal nodes have no outbound connections
};

Traffic Type Routing Logic

The color-coded traffic system routes requests based on type and available infrastructure:

// Traffic routing preferences from README
const trafficRouting = {
  STATIC: { primary: 'cdn', fallback: 'storage', reward: 0.50 },
  READ: { primary: 'readReplica', secondary: 'nosqlDb', fallback: 'sqlDb', reward: 0.80 },
  WRITE: { primary: 'nosqlDb', secondary: 'sqlDb', reward: 1.20 },
  UPLOAD: { primary: 'storage', reward: 1.50 },
  SEARCH: { primary: 'searchEngine', fallback: 'sqlDb', reward: 1.20 },
  MALICIOUS: { action: 'block', target: 'firewall', reward: 0 }
};

Note: The README does not expose full source code for these structures; the above represents the documented game mechanics that would drive implementation.

Advanced Usage & Best Practices

Start with Security, Not Scale

The README emphasizes this explicitly: "Always place a Firewall immediately connected to the Internet." Malicious leaks cost -5 reputation each — a single missed DDoS wave ends runs faster than capacity shortfalls. This mirrors production reality where visibility and control plane security precede performance optimization.

Exploit CDN Economics

Internet → CDN → Storage handles 95% of static traffic at low cost. The $60 CDN pays for itself rapidly versus routing static requests through compute. This teaches edge caching as default architecture, not afterthought.

Tier Your Database Strategy

NoSQL DB (150ms, READ/WRITE only) outperforms SQL DB (300ms) for its supported traffic. Reserve SQL DB for SEARCH fallback and complex queries. Add Search Engine (100ms, 3× faster than SQL) for SEARCH-heavy patterns. Use Read Replica to offload READ from master. This layered approach models real polyglot persistence strategies.

Monitor Serverless Cost Dynamics

At high RPS, Serverless Function's $0.03/request exceeds Compute's fixed costs. The game's Smart Hint warns when this threshold crosses. Use Serverless for spiky, unpredictable traffic; provision Compute for sustained baseline load.

Pre-scale Before Milestones

RPS multiplies at fixed intervals: ×1.3 at 1 minute, ×2.0 at 3 minutes, ×4.0 at 10 minutes. Build capacity ahead of these thresholds, not reactively. The 40-second traffic shift warnings provide limited reaction time.

Comparison with Alternatives

pshenok/server-survival occupies a unique niche: it's free, open-source, and simulates dynamic behavior without cloud vendor lock-in or subscription costs. The trade-off is scope — it models concepts, not exact AWS/GCP/Azure service semantics. For teams needing vendor-specific certification prep, AWS Cloud Quest or KodeKloud provide more targeted paths. For conceptual foundation and rapid experimentation, pshenok/server-survival's immediacy wins.

FAQ

What license is pshenok/server-survival under?

MIT License. Free for personal, educational, and commercial use.

Does it require Node.js or a build step?

No. Open index.html directly in any modern browser, or serve via any static file server.

Can I contribute or modify the game?

Yes — the repository is public. The vanilla JS stack makes modification accessible without framework expertise.

Is there multiplayer or leaderboard functionality?

Not documented in the README. The game appears single-player with local state.

How accurate is the cloud simulation?

It's a conceptual model, not a literal cloud emulator. Service capacities and costs are abstracted for gameplay balance, but the architectural relationships (CDN caching, queue buffering, read replica offloading) reflect real patterns.

Does it work offline?

Yes, once loaded. No external API dependencies are mentioned.

Where can I discuss strategies or report issues?

The README links to a Discord server for community discussion.

Conclusion

pshenok/server-survival succeeds because it makes cloud architecture feel consequential. The 6,151 stars suggest this approach resonates with developers tired of passive learning. Whether you're onboarding juniors, preparing for system design interviews, or validating your intuition about queue depths and cache hit rates, the game provides immediate, repeatable feedback loops.

It's best suited for: engineers transitioning into infrastructure roles, teams building shared vocabulary around scaling concepts, and anyone who's learned cloud theory but lacks operational intuition. The zero-cost, zero-setup barrier removes excuses — you can be playing in thirty seconds.

Clone it, break it, learn from the failure analysis screen, and iterate. The cloud won't get less complex, but your instincts for handling it can get sharper.

Explore pshenok/server-survival on GitHub →