The Parts of a System — What You Build In-House and What You Hand to External Services

This article is part of the IT Foundations course, which builds up from scratch the practical IT knowledge you need at a minimum for programming and vibe coding.
A web app splits into four parts: frontend, backend, database, and external services. Diagrams show how much you build yourself and where you start using an outside service.

This article covers the four parts that make up a web app.

You build three of them in-house (developing and setting them up yourself), and you use the remaining one as an external service.

The parts of my-app — the three you build in-house, and the external service
my-app (members-only booking app)
Parts you build in-house
Frontend
  • The screen for entering the booking date and name
  • Runs on the user's device
Backend
  • Processes the booking details it receives
  • The identity check happens here too
Database
  • Stores the booking and member data
  • Can be searched and updated later
The part you use as an external service
  • Sending confirmation emails, payments, showing maps
  • Calls features that another company operates
The outer frame is one app. The three in the upper frame are the parts you build in-house, and the lower frame is the part that uses features another company operates.

The line between building in-house and using a service is where these two frames meet.

A web app splits into four parts

The four parts are the frontend, the backend, the database, and external services.

What each of the four parts handles, and where it runs
Frontendthe screen sideBackendthe server sideDatabasethe stored dataExternal serviceanother companyDraws the screen,takes the inputProcesses the datasent and returns itStores data you cansearch and updateUses features runby another companyThe user's deviceServerServerAn outside server
Each row is one part. The left is the name, the middle is what it handles, and the right is where it runs. The only one that does not run on your side is the bottom row.
Which of the four parts connect to which
The user's deviceFrontendscreen and inputBackenddecide and processDatabasebookings, membersExternal serviceemail, paymentsBooking detailsRead and writeRequest via API
Left to right. Only the backend connects on both sides; the frontend has no direct connection to the database or the external services.

It is the backend that connects to the database and the external services, and the screen does not connect to them directly.

The server these two run on — a computer that stays powered on and can accept requests from other computers at any time — is a different computer from the user's device.

Only the fourth one, the external service, is not built in-house; you use what another company operates.

When something breaks, which one you can fix
SomethingbrokeFrontendbackend, DBExternal serviceYou can fix itWait for the othercompany to fix itFind the cause andfix the codeCheck the status,tell your users
One event on the left splits into an upper and a lower branch. The upper one you can fix, because the implementation is on your side; the lower one is run by another company, so you wait. The right is what you do then.

The three on the upper branch have their implementation on your side, so you are the one who fixes them.

The database is a product you choose and operate, but when it stops working, it is your side that steps in.

Only the external service is one you cannot fix yourself when it fails, and you wait for the other company to restore it.

Deciding what to hand over is also deciding what you cannot fix yourself.

Four parts, one boundary

A web app splits into four: the frontend, the backend, the database, and external services.

You build the first three in-house and use features another company operates only for the external services, so who provides the implementation and who handles a failure both change at this boundary.

External services are not built in-house; you use them through an API

Features that are a lot of work to provide yourself, such as sending confirmation emails or taking payments, are handed to external services.

The rules you follow when calling an external service are the API — the agreed rules programs use to exchange data with each other.

Even when you hand it to an external service, both ends stay with you
Build the addressand the bodyAsk it to sendthrough the APIThe service sendsthe emailTake the resultand record itYour jobYour jobThe service'sjobYour jobDecide whatto sendWrite it in theset formatDelivery and howmuch gets throughCheck whether itwas sent
The top row is the flow up to sending the confirmation email. Only the two in the middle are the external service's job, and the leftmost and the rightmost stay on your side.

Only the middle moves to the external service, and making the request and checking the result stay on your side.

What stays on your side is only sending the request and checking the result that comes back.

If you build it in-house, keeping it running becomes your job on top of the feature itself.

Even when you hand it over, sending the request and checking the result stay with you.

What moves to the external service is only the implementation.

External service and external API

You will sometimes see the two written separately: external service for what you call, and external API for the entry point you call it through.

They point at the same thing, and the difference is whether you look at it as a service or as an entry point.

Success or failure is decided independently for each part

One action can span several parts.

Whether a booking is confirmed is decided by the write to the database, and whether the confirmation email goes out is decided by the request to the external service.

A booking is confirmed the moment it is written to the database.

Sending the confirmation email happens afterward, as a separate request to the external service.

Even if the email does not arrive, a confirmed booking stays.

This split is directly useful when you investigate a problem.

"The booking is not there" and "the confirmation email did not arrive" send you to different parts.

For the first you check the backend and the database, and for the second you check the request to the external service.

Even for the same booking, the symptom changes which part you check
One bookingaction"The bookingis not there""The email didnot arrive"Did the backendreceive itDid the requestreach the serviceWas it writtento the databaseDid the servicemanage to send
The middle is one booking action. The upper branch and the lower branch succeed or fail separately, so a different symptom sends you to a different place.

The upper branch is the confirmation and the lower branch is the notification, and if one fails, the other stays as it is.

Success and failure are decided part by part

When one action spans several parts, success and failure are not decided all together.

A booking is confirmed by the write to the database and the confirmation email is decided by the request to the external service, so when a problem is reported, first work out which of the two failed.

QUIZ

Knowledge Check

Answer each question one by one.

Q1Which of a web app's four parts do you use rather than build in-house?

Q2What happens if the confirmation email does not arrive after the booking has been written to the database?

Q3When you hand sending the confirmation email to an external service, what stays on your side?

Back to IT Foundations