The Numbers After All the Fixes

After fixing the six bugs, here’s what the Green Algeria Map benchmark actually measured.

Baseline: 3 Backends at 1 CPU / 512MiB

All scenarios at 0% failure. Three repeats per scenario, median reported. 90s holds per run.

Auth (20 VUs, 30s hold)

Zones (40 VUs, 30s hold)

Mix (30 VUs, 1m ramp + 30s hold)

Notes: All three backends peaked at ~100% CPU under load (1 CPU limit). Go sips memory at 58MiB while NestJS and Spring Boot settle at ~390MiB due to runtime overhead. Spring Boot’s zones/mix latency is impacted by thread-per-request model at 512MiB - with heap limited to 154MiB, the remaining memory goes to native thread stacks.

Express vs Fastify

Swapping @nestjs/platform-express for @nestjs/platform-fastify made no meaningful difference:

All within run-to-run noise. The bottleneck is application logic: DB queries, serialization, auth. Not the HTTP adapter. Fastify uses slightly less memory (~10-30MiB), but the difference is marginal.

Spring Boot Virtual Threads

spring.threads.virtual.enabled=true changed nothing. At 40 VUs with a 1 CPU limit, the bottleneck was CPU-bound request processing. Not thread stacks, not the DB pool.

Commit: dc0eaed2

What’s Planned

The current benchmark tests everything together: framework, DB, auth, serialization. It can’t isolate where the bottleneck actually is. The next phase will run isolated scenarios:

• GET /ping: raw framework overhead
• POST /echo: JSON serialization cost
• POST /validate: validation cost
• In-memory CRUD: business logic without DB
• CRUD with PostgreSQL: DB layer isolation

Each layer measured separately to answer: is it the framework, the runtime, the ORM, the DB pool, the validation, or the auth?

Per-backend optimization posts will follow once the bottleneck is identified. The goal isn’t a winner. It’s understanding where each stack spends its time.