Choosing how the parts of a system fit
A software architecture style is a standard way to arrange the parts of a system and how they talk. Layers, services and events are three common styles.
The style you choose decides how hard the system is to change, to scale and to run. Picking one from the needs, and not from fashion, is a core design skill.
By the end of this lesson
Note
I can choose layers, services or events for a system from its needs.
Key words
| Word | What it means | Example |
|---|---|---|
| Architecture | the main parts of a system and how they connect | |
| Layer | a group of code that only talks to the one below it | |
| Service | a part that runs on its own and is called over a network | |
| Event | a record that something happened | Booking made |
| Scale | to cope with more users or more data | |
| Trade-off | a gain that costs something else |
The cells students fill in are left blank in this preview.
Layers stack parts, each using the one below
In a layered system the page talks to the booking rules, and the rules talk to the database. A layer never skips the one below.
Layers are simple to understand and to test. They suit a system that one team builds and one server runs.
The lab is a layered system
The lab has two layers: the web API on top and the database below. You can ask the database directly, or ask the API, and get the same three bookings.
The first Run counts the rows and prints 3. The second reads their ids through the API.
Give psql the password
export PGPASSWORD=shopShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Make the bookings table
psql -h db -U shop -c "drop table if exists bookings; create table bookings (id serial primary key, room text not null, slot text not null, booked_by text not null, hours int not null, status text not null default 'booked'); insert into bookings (room, slot, booked_by, hours) values ('Lab 2', 'Mon 10:00', 'Asha', 2), ('Lab 4', 'Mon 10:00', 'Ben', 1), ('Lab 2', 'Tue 14:00', 'Asha', 3); notify pgrst, 'reload schema'"Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Count the bookings in the database
psql -h db -U shop -At -c "select count(*) from bookings"Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Read the booking ids through the API
curl -s -w "\n" "http://api:3000/bookings?select=id&order=id"Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Services split a system into separate parts
A service runs on its own and is called over a network. A shop may have a bookings service and a rooms service, each with its own data.
Services let teams work and deploy separately, and let a busy part scale alone. The cost is more to run: every call crosses a network that can fail.
Events let parts react without being called
In an event style, a part records that something happened, such as "Booking made", in a log. Other parts read the log and react.
The part that made the booking does not know who reacts. A new reaction, such as a report, is added without touching it.
An event log keeps facts, not totals
Store each fact as a line: booked, booked, cancelled. The current state is worked out by counting.
The first Run writes three events and prints nothing. The next two count lines starting with booked, which prints 2, and cancelled, which prints 1. So one booking stands.
Write three events to a file
printf 'booked Lab2 Asha\nbooked Lab4 Ben\ncancelled Lab2 Asha\n' > events.txtShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Count the booked events
grep -c '^booked' events.txtShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Count the cancelled events
grep -c '^cancelled' events.txtShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A common mistake
Warning
Many people think services are always better than layers because big companies use them. Services add network calls and more to run. A small system with one team is simpler and safer as layers. Choose from the needs.
Worked example: which style fits
| Need | Style | Why |
|---|---|---|
| One team, one server, simple rules | Layers | Fewest moving parts |
| Parts must scale alone, many teams | Services | Each part runs and changes alone |
| Several things react to one happening | Events | New reactions need no change to the sender |
The cells students fill in are left blank in this preview.