From Tutorial to System

The Problem with Topic Lessons

Most backend courses — including several others in this Academy — teach one topic at a time: here's Gin routing, here's a Postgres migration, here's a JWT middleware. That's useful for building reference knowledge, but it hides the part that actually makes backend engineering hard: how a dozen individually-reasonable decisions interact once they're in the same repository, deployed together, under the same load.

A caching layer that looks correct in isolation can invalidate incorrectly once a second service starts writing to the same rows. An auth model that's clean on paper gets awkward the moment multi-tenancy is added after the fact. Those interactions are the actual job. They don't show up in a lesson about Redis alone.

What This Course Is

This course documents one real backend — Fieldwork — as it's designed and built, module by module, in the order the decisions actually had to be made. Go workspace structure comes before HTTP handlers, because you can't structure services sensibly without deciding module boundaries first. Multi-tenancy comes before the schema, because retrofitting tenant isolation into an existing schema is a materially different (and worse) problem than designing it in from the start.

• Every module maps to a real, reviewable piece of the Fieldwork repository — not a toy snippet.
• Every decision is presented with the alternative that was rejected, and why.
• Modules that describe planned-but-not-yet-built work are labeled explicitly — nothing is presented as working code before it exists.

What This Course Is Not

It's not a Gin tutorial, a Kafka tutorial, or a Kubernetes tutorial in isolation — the Academy already has dedicated courses for the fundamentals of building backend applications and Go for SRE tooling. This course assumes that ground and starts one level up: what happens when those fundamentals have to coexist inside one multi-service, multi-tenant system.

It's also not a case study for a specific company or client. Fieldwork's domain — a workspace and task-tracking API — was picked deliberately because it's boring. The domain exists only to give every architectural decision something concrete to attach to; it is never the point of a lesson.

How Content Ships

Modules are ordered the same way the project is actually built, not reordered afterward for narrative polish: workspace layout before HTTP handlers, the data layer before the API, auth before the gateway, resilience and observability once there's a real system worth protecting. Where a module covers something genuinely forward-looking — like the Kafka event bus — the lesson says so directly and grounds the design in the same schema and services built in earlier modules, instead of pretending it's already running in production.