10 parts · 12 chapters

Backend Architecture and Scale

The backend mirror of the Frontend Architecture course: how to shape a backend so that many teams can change it safely for years. Architecture is mostly about boundaries: which code may call which, which service owns which data, and which failures stay contained.

Ten parts: choosing between a monolith, a modular monolith and services honestly; hexagonal and clean architecture in real TypeScript; DDD tactical patterns; data ownership and service boundaries; event-driven architecture, choreography and orchestration; synchronous versus asynchronous integration; multi-tenancy designs; and three incident logs written the way post-mortems are: the distributed monolith, the shared database and the event storm.

monolith to services · hexagonal and clean architecture · DDD tactics · data ownership · events · sync vs async · multi-tenancy · three incident logsmid → staff · backend engineers and tech leads
shapeMonolith, modular monolith or services, chosen by team and change pattern.
insidePorts and adapters, aggregates, repositories, domain events.
boundariesOne owner per piece of data; contracts between owners.
integrationCalls versus events; choreography versus orchestration.
tenantsPooled, bridged and siloed tenancy, and noisy neighbours.
failureThree incidents that come from architecture, not code.
Built on System Design and Distributed SystemsUses Backend System Design for components, Distributed Systems for failure, and Ledgers for the running payments example.