Architecture

Saving the result of slow work somewhere fast so the next person who needs it gets it instantly. The first time something is calculated or fetched it's slow; every time after that, the saved copy is handed out until it gets too old to trust.

A rule about systems that store data on many computers at once. It says you can have at most two of three things: everyone always sees the same data, the system always responds, and the system keeps working even when the computers can't talk to each other. You always have to give one up.

A worldwide network of computers that keep copies of a website's images, videos, and other files in many cities at once. When you visit the site, you're served from the nearest copy. So the page loads faster and the original server isn't overwhelmed.

The basic shape of most apps and websites. The client is the program in front of you, your browser, your phone app, and the server is a powerful computer somewhere else that does the heavy lifting and stores the data. The client asks for things, the server answers.

A way of building software where different parts don't call each other directly. Instead, one part announces 'something happened' and any other part that cares can react. This keeps the pieces loosely connected, so adding new reactions is easy.

When data is stored in many places at once, an update doesn't reach all of them at the exact same moment. For a brief time, different copies might disagree. But if you wait a beat, they all catch up and end up matching.

A traffic cop that sits in front of a group of servers and decides which one each visitor should go to. It spreads people out so no single server gets crushed by the crowd, and it stops sending traffic to any server that's broken or too slow.

A waiting line for tasks. One part of the app drops jobs into the queue; another part picks them up and works through them at its own pace. This means slow work doesn't make people stand around waiting, and a sudden rush of jobs doesn't crash anything.

A way of building a big app by splitting it into many small, independent programs that each handle one job. The payments program, the search program, and the notifications program are all separate, run on their own, and can be updated without touching each other.

An app where every feature lives in one big program that gets built and launched all together. It's the opposite of splitting things into many small services. Monoliths are simple to start with, and most apps begin this way, but can get unwieldy as they grow.

A classic recipe for organizing an app into three pieces. The Model is the data and the rules about it. The View is what the user sees on the screen. The Controller is the middleman that takes user actions and updates the data or the view in response.

A messaging pattern that works like a magazine subscription. One part of the app publishes announcements to a topic without knowing who's listening. Anyone who's subscribed to that topic gets a copy automatically. And you can add new subscribers anytime without telling the publisher.

A guiding rule for keeping code tidy: each part of a program should have one job and stay out of the others' business. When jobs are mixed together, a small change in one place can quietly break something completely unrelated.

A way of running code in the cloud where you don't manage any servers yourself. You upload your code, and the cloud provider runs it on demand: automatically starting it up when needed and shutting it down when it's idle. You only pay for the seconds it's actually running.