Back to Lab
Interactive Environment

Backend Engineering Simulator

An interactive learning platform simulating real-world backend incidents and debugging scenarios.

Source CodeFull Lab README
Browser simulation: this page uses scripted logs, metrics, and dependency states to demonstrate the investigation workflow. The linked source project is the larger lab intended to run real Spring Boot services and injected failures.
Difficulty:Senior
Incident: Cascading Failure
Topics
Incident ResponseDistributed SystemsDebugging

Incident Workflow

Follow the map or press the next-step button. This is a scripted browser scenario, not a live production shell.

user@systems-notebook: ~/incident/auth-service-outageACTIVE
SYSTEM BOOT: Backend Engineering Simulator v2.0.0
[SEV-2] Login success rate dropped from 98.4% to 41.7%.
Scenario active: auth-service outage with suspected persistence saturation.
Type "help" or use the command buttons to begin the investigation.
$
Project Notes

The Vision

Most tutorials teach you how to build a system when everything goes right. The Backend Engineering Simulator teaches you what to do when everything goes wrong.

This portfolio version is a compact browser-native scenario inspired by the larger Backend Engineering Lab project. It does not connect to live infrastructure; the logs, metrics, dependency health, and command responses are scripted to demonstrate the investigation workflow.

The full lab is designed around Spring Boot services, PostgreSQL, Redis, Kafka, Prometheus, Grafana, fault injection, scenario catalogs, dependency health, and exportable incident reports.

  • Source code
  • Live hosted demo: not deployed yet. The portfolio page above is the lightweight browser simulation; the full lab currently runs locally with Docker and the project scripts.

Scenario Model

The simulator follows a senior incident-response loop:

  1. Identify the affected user journey.
  2. Inspect service health and dependency boundaries.
  3. Collect logs, metrics, and trace evidence.
  4. Test a hypothesis without making the outage worse.
  5. Apply an immediate mitigation.
  6. Write the root cause and long-term remediation.

Why The Terminal Exists

Visitors do not need to open their real terminal. The browser terminal is a teaching interface. It turns backend concepts into concrete investigation actions:

  • status reveals service health.
  • logs auth-service exposes the failing boundary.
  • metrics auth-db-primary shows saturation.
  • trace login follows one failed request.
  • inspect batch-job identifies the upstream cause.
  • kill batch-job applies mitigation.
  • resolve prints the final RCA.

The interaction demonstrates how a backend engineer narrows a production incident from symptoms to evidence-backed diagnosis.

Connection To The Larger Lab

The local Backend Engineering Lab expands this idea into a full training platform with multiple fault-injection scenarios:

  • API contract regression
  • OpenAPI schema drift
  • API latency degradation
  • Database connection failure
  • Cache stampede
  • Write-path failure
  • Memory leak
  • Kafka consumer lag
  • Saga boundary failure
  • Rate limiting

The portfolio keeps one guided incident polished enough for recruiters, engineering managers, and founders to understand the engineering judgment behind the larger project.