Backend from First Principles: Visual Flow
A single guided map through HTTP, routing, serialization, auth, validation, APIs, databases, queues, observability, security, scaling, and concurrency.
Blog
I write about software engineering, system design, and the concepts behind how things work — explained through mental models that stick.
A single guided map through HTTP, routing, serialization, auth, validation, APIs, databases, queues, observability, security, scaling, and concurrency.
AWS for Backend Developers
Concurrency is not "doing everything at once." It is "not wasting the CPU while one task is waiting."
Performance engineering is not "make it fast." It is "find exactly where time is being spent, then remove the right bottleneck with the least complexity possible."
Most security bugs start with one dangerous sentence: "The user will probably not do that." Attackers build careers out of doing exactly that.
The most dangerous server restart is the one that looks instant. Because "instant" usually means somebody got cut off mid-request.
Monitoring tells you something is broken. Observability tells you what. The whole topic is about understanding the inside of a system from the outside — because in production, you don't get to do anything else.
Most engineers think configuration is "env vars for API keys." That's like saying a car is just its engine. Configuration is the DNA of your backend — and the place where most production disasters quietly live.
Your code will fail in production. The only question is how you handle your errors. That's the entire job of error handling.
If you've ever written WHERE name ILIKE '%laptop%' in production, you've already met the problem this article solves. You just haven't felt it yet.
Not everything needs to happen before the user gets a response. That's the entire philosophy of background jobs.
The fastest database query is the one you never make. That's caching in one sentence.
Every backend system eventually asks the same question: "Where does the data live when the server shuts down?" The answer is a database. And how you design it determines whether your system scales or collapses.
You'll spend more time designing APIs than almost any other backend task. A well-designed API is invisible — developers integrate and move on. A poorly designed one generates Slack messages at 2 AM asking "what does this endpoint even return?"
Separation of concerns isn't about elegance — it's about survival at scale. Here's how to organize your backend into layers that actually work.
Validation is the bouncer at the door. Every 500 error, database crash, and injection attack traces back to data that should have been rejected. Here's how to think about it.
Every backend system faces two questions: 'Who are you?' and 'What are you allowed to do?' Here's the mental model that makes sessions, JWTs, OAuth, and RBAC click.
Your JavaScript frontend speaks JS, your Rust backend speaks Rust. How do they communicate? Through the universal translator pattern of serialization.
If HTTP is the what and how of communication, routing is the where. Understanding it deeply separates engineers who use frameworks from engineers who understand them.
Every backend system sits on top of HTTP. Let's build a mental model that makes every concept click into place — from methods and headers to CORS and caching.