Backend code turns an incoming request into a result. The useful design questions are concrete: where do we validate input, where do business rules live, who owns a query, what does a retry do, and what happens when work waits or races?
This section builds that model in three connected parts:
- Architecture follows a request through routing, handlers, services, repositories, middleware, and request context.
- API design covers resource URLs, HTTP methods, CRUD responses, list queries, and consistency.
- Concurrency explains threads, event loops, goroutines, and the races caused by shared mutable state.
Follow one request
Start with the request lifecycle. It gives the whole path before the individual pages explain each seam. Then read handlers and controllers, services, and repositories.
The layers are a design pattern, not a law. A small application may keep two layers together. Add a seam when it hides real complexity or gives tests and callers a simpler interface.
Choose an interface before an implementation
Read API design after the lifecycle. An HTTP interface names resources, defines method semantics, and gives clients stable success and error shapes. URL design and methods and idempotency are good starting points.
Storage and cache choices belong with their access patterns and consistency needs. See databases, caching, and availability and consistency for the system-design view.
For live updates, read real-time backends. It connects the API write path to event delivery, persistent connections, reconnection, and multi-instance fan-out.
Make waiting and shared state explicit
Most backend work waits on a database, another service, or a file. Concurrency and parallelism explains why that wait does not need to idle a CPU. Then compare threads, the event loop, and goroutines.
When tasks share mutable state, read race conditions before adding locks or channels. Asynchronous processing covers work that should leave the request path entirely.