Projects — High-Load & Big-Data Engineering Labs¶

Hands-on project briefs for senior and staff Go backend engineers.

These are not CRUD toys. Every project makes you stand up a real system (Kafka, ClickHouse, Postgres, Redis, Elasticsearch…), generate large datasets, drive high load, then measure, break, and tune it until you can defend the numbers. The skill being trained is not "can you make it work" — it's "can you make it work at scale, explain why it behaves the way it does, and prove it with data."

Each brief is a TZ (техническое задание / technical specification): a realistic problem, hard requirements, explicit SLOs, a load-and-data profile, a set of experiments to run, and a grading rubric a staff interviewer would recognize.

How to use a project¶

1. Read the whole TZ first. Note the SLOs and the dataset scale — they drive every design decision.
2. Generate data at the stated scale before you optimize anything. Tuning against 1k rows teaches you nothing; the interesting behavior starts at 10M+.
3. Build the smallest thing that meets the functional requirements, then run the load harness and watch it fall over.
4. Run the experiments. Each TZ lists "break it / tune it" investigations. Record before/after numbers (throughput, p50/p99/p999, lag, CPU, allocations).
5. Write a short findings note per project: what you changed, what it bought you, and why. This is the artifact that proves staff-level depth.

You do not need to finish every stretch goal. You do need numbers you can defend. Depth over breadth — one project taken to real scale with a written findings note beats eight half-built repos.

The scale matrix — build every project in 4 stages¶

"High load" isn't one thing. It has two independent axes — data volume and request rate — and they fail in completely different ways. So every project is a 4-rung ladder. Build Stage 0 correct first (it's your control); then push each axis on its own; then push both together. Don't tune what isn't yet correct.

The two axes are independent: a system can ace Stage 1 and fall over at Stage 2 (or vice versa). Stage 3 is the production boss fight where they compound. A project is only "senior/staff done" at Stage 3 — measured and defended.

Each project instantiates the axes in its own terms (a rate limiter's "big data" = millions of keys; a columnar store's "high RPS" = many concurrent queries). The stages map onto the TZ sections: Functional reqs → 0; Load & data profile → 1; load harness + SLOs → 2; Experiments + full SLOs → 3.

Tiers¶

• labs/ — Data-systems load labs. The core of this library: push a single technology (Kafka, ClickHouse, Postgres indexes, Redis, ES) to its limits with big data and learn its failure modes.
• senior/ — Own one service end-to-end, with high load baked into the requirements. You design the data model, the API, and the scaling story.
• staff/ — Cross-cutting, ambiguous, multi-system problems at scale: consensus, sharding, multi-region, migrations, exactly-once pipelines.

Catalog¶

labs/ — Data-Systems Load Labs¶

events/ — Event-Engineering Labs¶

resilience/ — Rate-Limiting & Resilience Labs¶

load-testing/ — How to Test High Load (the meta-skill)¶

observability/ — Logging & Monitoring at scale¶

distributed-patterns/ — Coordination & Distributed-Transaction Patterns¶

networking/ — Sockets & Network Performance¶

senior/ — Service builds (high-load baked in)¶

staff/ — Systems at scale¶

Each project tags 3–5 interview sections; the catalog collectively covers all 23.

Shared tooling conventions¶

Every TZ assumes these, so they aren't repeated in each brief:

• Local infra: docker-compose (or kind for k8s labs) brings up the dependency. Pin versions; record them in your findings.
• Dataset generator: a Go program (cmd/gen) that produces data at the target scale with realistic distributions (Zipfian for hot keys, skewed cardinality where it matters). Deterministic via a seed so runs are reproducible.
• Load harness: k6, vegeta, or a custom Go driver. Drive a defined traffic profile (open vs closed model; state the model). Capture a full latency histogram, not just an average.
• Measurement: p50 / p95 / p99 / p999 latency, throughput, error rate, and the resource cost (CPU, memory, allocations via pprof, disk/network I/O). An average with no tail is not an answer.
• Reproducibility: every number in your findings note must come with the command and config that produced it.

Global evaluation rubric¶

Each TZ has a project-specific rubric; all of them inherit this spine:

A project is "done" when you can put its findings note in front of a staff engineer and defend every number on it.

See the parent Interview Question/ bank for the matching theory.