How a Web Service Works — IT Fundamentals for Absolute Beginners

About this article

Thank you for visiting the site. This article is part 1 of the “IT Fundamentals” primers in the Architecture Crash Course for the Generative-AI Era series, and it covers how a web service actually works.

The series calls itself a “crash course”, but honestly, the main articles are written assuming you already know roughly what a server or a database is. So I have put together these primers to build enough groundwork that someone with essentially no IT background can start reading the main series.

In this article I explain what happens behind the web services we use every day — online shops, video sites and so on — using nothing but a “restaurant” analogy. There is almost no jargon, and where a term does appear I always explain it on the spot, so you can read on without worrying.

What a web service is in the first place

Roughly speaking, a web service is “anything on the internet you use through a browser or a phone app”.

Buying something from an online shop, watching a video, checking your bank balance — those are all web services. This blog you are reading right now is a small one too.

Here is something worth stopping on. When you search or shop in your browser, where is that screen, and that product information, actually coming from?

Obviously your phone or laptop does not contain every product and every video in the world. In reality it is being fetched, each time, from “a computer somewhere far away”. And once you understand the shape of that “fetching arrangement”, the whole series gets much easier to read.

From typing a URL to seeing the page

Between pressing enter on a URL and the page appearing, this is what happens behind the scenes.

Let me walk the diagram through in words.

1. The browser places an order — a request saying “please show me this page” (the technical term really is a “request”) travels across the internet to the other computer
2. The server takes the order — a server is simply “the shop’s computer”, the one that receives orders and answers them
3. A program cooks — depending on what was ordered, a program works out which information to assemble and how
4. The database supplies the ingredients — recorded information such as product details and member accounts is pulled out of a purpose-built store called a database
5. The finished page comes back — the assembled result reaches the browser and appears as the screen we look at

Every button press, every page open, repeats those five steps. And in most cases the whole sequence is over in less than a second. Stop and think about it and that is a fairly remarkable arrangement.

The same thing, as a restaurant

Let me re-organise that flow as a restaurant, because the cast of a web service maps onto the cast of a restaurant remarkably cleanly.

Keep that table somewhere at the back of your mind. The main series throws around “frontend”, “backend” and “database” as if everyone knows them, so whenever you lose the thread, substituting “ah, this is about front of house, the kitchen and the store room” should be enough to follow the argument.

Client and server: the one who asks, and the one who answers

One step further. In IT, “the one who asks” is called a client and “the one who answers” is called a server.

In the restaurant, the customer is the client and the shop is the server. Browsers and phone apps are both on the ordering side, so they are all clients. A web service, then, is built on a division of labour between clients and servers.

So why divide it at all? The big reason is “we want the information managed in one place”. If stock levels were stored separately inside everybody’s phone, then every time one person bought something you would have to go and rewrite the stock count on everyone else’s phone as well. Impossible on the face of it. Have the shop side hold it all and answer when asked, and there is exactly one copy, and everyone sees the same current state.

Frontend and backend: looks and internals

The shop itself is divided too.

The frontend is front of house: how the menu is presented, how orders are taken, how food is delivered — everything the customer’s eyes ever land on. In web terms, the screen design, the button layout, how the input form behaves.

The backend is the kitchen. It is the part that actually makes what was ordered: “decrease the stock by one”, “record the payment”, “check whether this person is a member” — the processing the customer never sees directly.

Why split them? Same reason as the restaurant: the skills required are different. Being good with customers and being good at cooking are separate talents. In IT too, building the look and building the internals are separate specialisms, and on large teams they are separate people. That is why the series has a whole category called “Frontend Architecture”.

The database, and why a spreadsheet will not do

A little more on the store room.

If you thought “if it is only keeping records, would a spreadsheet not do?” — that is a good instinct. The inside of a database really is a collection of tables, so conceptually you are close.

But the store room of a web service has one special condition a spreadsheet cannot survive: thousands or tens of thousands of people reading and writing at the same time.

What happens if ten thousand people try to write in one ledger at once? Queueing and mistakes, presumably, and chaos. And if two people buy the last remaining item at the same moment and both get told “purchase complete”, that is a serious incident. A database is a purpose-built store room, made to direct that simultaneous traffic safely.

So the “Data Architecture” category of this series is, at bottom, an extended argument about how to design and choose that store room.

Where servers actually are, and what the cloud is

Finally, a word about the “location” of the premises.

A server is basically just a high-performance computer. Companies used to buy them and put them in a room in their own building (that arrangement is called “on-premises”). Owning them, though, means handling every failure and every power cut yourself.

What became mainstream instead is the cloud. Roughly, the cloud is a service that rents you as much computing as you need out of an enormous data centre. In restaurant terms, instead of putting up your own building, you take a fitted-out unit and trade from there.

Renting makes it easy to move to a bigger unit as customers arrive, and the cleaning and building maintenance are the landlord’s problem. AWS, which appears constantly in the main series, is the largest of these landlords, run by Amazon.

With this mapping, the main series becomes readable

With all of that in your head, the categories of the series sort themselves into “which part of the restaurant is this about”.

• Frontend Architecture — designing front of house: presentation and service
• Software / Application Architecture — designing the kitchen: the recipes and the order of work
• Data Architecture — designing the store room: keeping and managing ingredients
• System Architecture — designing the building, the location, the utilities
• Security Architecture — locks, theft prevention, hygiene
• DevOps Architecture — getting ready to open, and keeping the place running every day

So the series is really “a design manual for opening a restaurant, making it busy, and keeping it running for years”, split up by who does what. Framed that way, eighty-odd articles feel a bit more approachable. The whole map is laid out in the series entry point, which is worth a look.

Architecture Crash Course for the Generative-AI Eraen.senkohome.com/arch-intro-overview/

Related articles

Summary

This article covered how a web service works, following the whole path from browser to database through a restaurant analogy.

The customer who orders (the client) and the shop that answers (the server); then front of house (frontend), the kitchen (backend) and the store room (database). With that mapping in mind, you should be able to pick up the broad shape of any article in the main series, whichever one you start with.

The next primer goes a level deeper into the building itself: “servers and the cloud”.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.