Programs vs services: why a backend never "finishes"
On This Lesson 11 topics
Lesson Overview
Most software you have used so far does a job and stops. You open a calculator, add two numbers, close it. The work is finished and the process ends. But the backend you met in the last lesson behaves differently: it is switched on and stays on, waiting for the next request, hour after hour, day after day.
In this lesson you will learn the difference between a program that runs and exits and a service that runs continuously, why a backend is the second kind, and what follows from that: it must be reliable, it must serve many users, and its stopping has consequences.
In the restaurant picture, a program is like a cook who makes one meal and goes home. A service is like the restaurant itself, which stays open and waits for customers, all day.
Why this matters: nearly everything you will build in this course path is a service. How a service starts, waits, answers, and fails is the core of backend engineering.
This lesson builds on the previous lesson (backend runs on a server) and on Module 1 (process, operating system, RAM).
Learning Objectives
By the end of this lesson you will be able to:
- Describe a program that runs and exits, with its start, work, and end.
- Describe a service that runs continuously, and what it does while it waits.
- Explain why a backend is a service and "never finishes".
- Classify examples as program or service, and justify each.
- Explain the request and response pattern in plain language.
- Describe what happens to the people who depend on a service when it stops.
- Distinguish a service that is "idle" from one that is "broken".
Written Explanation
Two ways to run
From Module 1 you know that when software runs, the operating system creates a process for it. A process has a beginning (it starts) and an end (it exits or is stopped). What matters now is how long it is meant to live and what it is waiting for.
There are two common patterns.
| Program that runs and exits | Service that runs continuously | |
|---|---|---|
| Meant to live | Until the job is done | Until someone stops it on purpose |
| Starts when | Someone starts it | The system or an operator starts it |
| Work | A fixed job with a clear end | A never-ending series of small jobs, one per request |
| Ends when | The job is done | Rarely; stopping is an event worth noticing |
| Example | A calculator, a file converter, a script that renames photos | A website's server, a banking server, a chat server |
Neither pattern is better. They fit different jobs.
The program that runs and exits
A program that runs and exits (sometimes called a batch job or a one-shot program) has a simple life:
start -> read the input -> do the work -> show or save the result -> exitThink of a cook who comes in, makes one specific meal, hands it over, and leaves. The cook does not stay behind waiting for another order that may never come.
Examples:
- A calculator opened to add numbers. Close it, and its process ends.
- A photo converter that turns 100 pictures from one format into another, then stops.
- A backup script that copies files overnight, reports "done", and exits.
You decide when to start these, and when they finish, the process is gone from the list you saw in Task Manager or Activity Monitor in Module 1.
Note: a calculator app that stays open while you think is still a program, not a service, because it is only meant to run for your session. It serves one user, on that user's request, and ends when the user closes it. The key is that it has an ending built into its purpose.
The service that keeps running
A service is software that is started and then stays running, waiting for work to arrive. It does not finish, because its purpose is not one job, but being available for any number of jobs that arrive whenever someone wants.
start -> prepare -> WAIT for a request -> handle it -> send an answer -> WAIT again -> ...
^____________________________________________|This loop is the heart of a backend. A backend is not "run once with the orders and exit". It is "stay ready; whenever a request comes in, handle it, then go back to waiting".
Think of the restaurant itself. It does not "complete" when one customer leaves. The door stays open, the kitchen stays staffed, and the next customer is served in the same way.
Terminology note: people also say daemon for a long-running background program on Unix-like systems, and operating systems have their own tools for running services (for example, Windows has a Services tool, and Linux commonly uses a system manager called systemd). You do not need these names now; the idea is what matters. If you hear them later, they mean "software that is meant to keep running in the background".
The request and response pattern
How does a service know there is work? Someone asks it. This is the request and response pattern:
- A client (a phone app, a browser) sends a request: "give me the menu of restaurant 42" or "save this order".
- The service receives it, does the work, and sends a response: the menu, or "order saved".
- The service goes back to waiting.
The web works this way: according to MDN, the client always starts the exchange, and the server answers; the server does not start conversations on its own. That is why a backend must always be there: it cannot go and find its clients, it can only be ready when they come.
You will learn the details of this pattern (HTTP, the language clients and servers use) later in the course. For now, keep the picture: a client asks, a service answers.
Why a backend never "finishes"
Now the main question. Why does a backend not just run and exit like a program?
- Requests can arrive at any time. A food app may get an order at 12:03, another at 12:03 and one second, and one at 3 a.m. from a customer in a different time zone. A program that exited after the last order would be gone when the next one arrived.
- Starting takes time. A service often has to load its settings and connect to its data when it starts. Doing that for every single request would be slow. It is better to start once and handle thousands of requests.
- Users expect availability. People expect the app to work whenever they open it. If the backend is not running, the app cannot do anything useful.
- It holds state in RAM while it runs. A running process can keep useful information in RAM (Module 1), such as connections to a database. This is part of why it stays running, though important data must still be saved to storage, because a restart empties RAM.
So "never finishes" does not mean "never stops" in the literal sense. A service may be stopped for a software update, restarted after a crash, or moved to another machine. It means that finishing is not its normal state. A service that has exited is an incident that someone has to deal with.
Idle is not the same as broken
A service with no requests is not doing nothing wrong. It is idle: waiting, using very little CPU, ready. That is the healthy state at 3 a.m.
A service is broken when it should answer but cannot: it crashed, it cannot reach its data, or it is overloaded. From outside, a broken service and an idle one can look similar (nothing visible is happening), so engineers need ways of checking that a service is truly alive. Later in the course you will learn about such checks. For now, notice that the question is not "is it busy?" but "does it answer when asked?"
Serving many users at once
A program usually serves one user: you. A service serves many users, often at the same time. Imagine one request that takes two seconds to answer. If the service could only handle one request at a time, the hundredth user in the queue would wait minutes. So services are built to handle many requests during the same period, which is why server computers have many CPU cores and plenty of RAM, as you saw in Module 1. The techniques come later in the path. The point for now: continuous operation and many users go together.
What happens when a service stops
Because many people depend on it, a stopped backend affects them all:
- A phone app shows errors or spins forever.
- A website loads its page, but the data does not appear, since the page (a frontend) has nobody to ask.
- A shop loses orders during the outage.
This is why backend engineers care about reliability: designing the service so that it keeps running, recovers quickly, and does not lose data when something fails. Reliability is a theme through the rest of this course.
Examples
Example 1: a calculator and a web server side by side (simple)
| Calculator | Web server of an online shop | |
|---|---|---|
| Who starts it? | You, by opening it | The company, once, when setting up |
| What does it do? | One calculation at a time for you | Answers requests for any customer |
| When does it end? | When you close it | It is meant not to end |
| Pattern | Program | Service |
If you close the calculator, nobody else notices. If the shop's server stops, every customer is affected.
Example 2: a log of a service day (practical)
Imagine a small order service. Here is a made-up log of what it did on one morning. The times are invented to show the shape of the pattern.
07:58 Service started. Connected to the order database.
07:58 Waiting for requests.
09:12 Request: save order 1001. Response: saved.
09:12 Waiting for requests.
09:13 Request: show order 1001. Response: sent.
09:13 Waiting for requests.
(a long quiet period; the service is idle, not broken)
11:47 Request: save order 1002. Response: saved.
11:47 Waiting for requests.Notice what is not in the log: there is no "Finished" line. After every response, the service goes back to waiting. The long quiet gap is normal.
Contrast this with a program that renames photos:
10:02 Started. Found 100 photos.
10:03 Renamed 100 photos.
10:03 Finished. Exit.The program ends. The service does not.
Example 3: a payment service and a bad night (realistic)
An online shop's payment service runs on a server all year. One night, an operator restarts the server to apply an update and forgets to start the payment service again.
- The service is not running: a request to charge a card receives no answer.
- The shop's website still loads (its frontend is fine), and customers can fill their baskets.
- When a customer presses "Pay", the website sends the request to the payment service. Nobody answers. The customer sees an error.
- The shop loses sales until someone notices and starts the service.
Several lessons come out of this: a service has to be started again after a restart, someone has to notice quickly when it is not running, and the effects reach the customers through the frontend. The website was working while the system as a whole was not, and that is another reminder that a website is not its backend.
In real systems, tools restart services automatically and send alerts when they stop. You will meet some of these tools later.
Backend Insight
As a backend engineer you will write software that is expected to stay up. Several habits follow from this lesson:
- Think in requests. The unit of work is one request: arrives, is handled, is answered. Everything else is waiting.
- Think about the long run. A program that is closed after a minute can afford small inefficiencies. A service that runs for weeks must not slowly fill up RAM or lose track of resources, because it will not be restarted soon. Problems that take days to show are real problems for services.
- Expect restarts. Services are stopped for updates and sometimes crash. Data that matters must be in storage (Module 1) before you tell the user it is done, because RAM is lost on restart.
- Remember your users are many. One slow or broken request is probably not alone; it may be hundreds at once.
The word "service" has a second meaning that you will meet later: a service can also be a part of a bigger system, like a payment service next to an order service. In both meanings, a service is software that runs continuously and answers requests from other software or people.
Common Mistakes
Mistake 1: Treating a backend as a program that runs once
- Incorrect: "I run my backend, it sends the answer, and it is done."
- Correct: "My backend starts, waits, answers request after request, and keeps running until someone stops it."
This is the most basic mental model error, and it is why a first backend can feel strange: you start it and nothing seems to happen. That is correct. It is waiting.
Mistake 2: Thinking a quiet service is a broken service
A service with no traffic is idle. Check whether it answers, not whether it looks busy.
Mistake 3: Thinking that "never finishes" means "never stops"
Services are stopped and restarted regularly for updates and fixes. The point is that stopping is a deliberate event, not the normal end of a job. A planned stop should be short and safe; an unplanned stop is a problem.
Mistake 4: Keeping important data only in RAM
A service keeps running, so it is tempting to keep everything in RAM. But a crash or restart wipes RAM. Anything that must survive, such as orders, goes to storage.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. Define "program that runs and exits" and "service" in one sentence each.
Show solution A1
A1. A program that runs and exits does a specific job and ends when the job is done. A service starts and keeps running, waiting for requests and answering each one.
A2. Classify each as a program or a service: (a) a script that resizes 50 photos and stops, (b) the server behind a messaging app, (c) a PDF converter that you run on one file.
Show solution A2
A2. (a) Program. (b) Service. (c) Program.
A3. In the request and response pattern, who starts the exchange: the client or the service?
Show solution A3
A3. The client. The service waits and answers.
Level B: Application
B1. Sketch the life of a service as a loop using the words start, wait, handle, and respond.
Show solution B1
B1. Start, then wait; when a request arrives, handle it and respond; then wait again. The loop from wait to handle to respond and back to wait repeats until someone stops the service.
B2. A service has had no requests for six hours. Is something wrong? How would you check?
Show solution B2
B2. Not necessarily: six hours of silence may just mean it is idle, for example at night. To check, send it a test request and see whether it answers correctly, or use whatever health check the team has set up. What matters is whether it answers, not whether it looks busy.
B3. Explain why a restaurant is a better picture for a backend than a single cook who makes one meal.
Show solution B3
B3. A restaurant stays open and ready for any customer who arrives at any time, like a service. A cook who makes one meal and leaves is like a program that runs and exits and would be gone when the next customer came.
Level C: Challenge
C1. A team's order service crashes once a week at 4 a.m. and nobody notices until customers complain at 8 a.m. Name two things the team could do (in general terms) to reduce the harm, and say why each helps.
Show solution C1
C1. For example: (1) set up automatic restarts, so the service comes back within seconds without waiting for a person; (2) set up monitoring and alerts, so the team learns about the crash right away. Restarts reduce the length of the outage and alerts reduce the time before anyone acts. Finding the cause of the weekly crash is also important, but it takes longer than reducing the harm.
C2. A developer writes a backend that keeps all customer orders in a list in RAM and says "it is fast and simple". Describe what happens at the next restart and what should change.
Show solution C2
C2. At a restart, RAM is emptied, so every order in the list is lost. The orders should be written to storage, usually through a database, before the service tells the customer that the order is saved. RAM can still be used as a fast copy in addition.
Mini Challenge
Find one program and one service on your own computer or phone and write a short comparison.
- Open the process list from Module 1 (Task Manager, Activity Monitor, or
top). Name one thing that you started and will close when you are done (a program in the sense of this lesson). - Name one process that seems to run all the time in the background. If you do not know what it is, say so; do not guess, and search for its name if you wish. Hedge your answer: some background processes belong to the operating system.
- For each, write when it starts, what it waits for, and when it ends.
- Write one sentence on what would happen to you if the background one stopped.
Check your work: you wrote a clear end for the program, and for the service you wrote what it waits for. If you were unsure about a process, you wrote that instead of guessing.
Summary & Next Lesson
Key takeaways
- A program that runs and exits does a job and ends. A service starts and keeps running, waiting for requests.
- A backend is a service: it answers many users at any time, so it must stay available.
- The request and response pattern: the client asks, the service answers and goes back to waiting.
- A quiet service is idle, which is normal. A service is broken if it cannot answer when asked.
- "Never finishes" means that finishing is not the normal state. Services are still stopped for updates or crash sometimes.
- Data that must survive a restart goes to storage, not only RAM.
Next lesson
Software is never "done" even after it is released: it is kept running and changed. The next lesson, "The software lifecycle", names the seven stages in the life of a piece of software, from the first idea to retirement.
Self-check
- What is the difference between a program that exits and a service?
- Why can a backend not just run once and exit?
- Who sends the first message in the request and response pattern?
- Is a service with no traffic broken?
- Why should orders be written to storage and not just kept in RAM?
Show answers
- A program does its job and exits. A service starts and keeps running, waiting for requests.
- Requests can come at any time from many users, so the backend must be there whenever they arrive.
- The client.
- Not necessarily. It may be idle. It is broken only if it cannot answer when asked.
- RAM is emptied by a restart or crash, so data kept only there is lost, while storage keeps it.
References
- MDN Web Docs, An overview of HTTP. Supports the statements that HTTP is a client-server protocol, that clients send requests and servers respond, and that the client always starts the exchange.
- MDN Web Docs, What is a web server?. Supports the description of server software that waits for incoming requests and answers each one.
- The program versus service contrast, the restaurant picture, the invented log, and the payment-outage story are this course's own teaching material. The mentions of daemons, the Windows Services tool, and systemd are given as general background and I did not verify them against official documentation, so treat them as pointers to look up later.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.