In this chapter
We'll learn why the way you organise data decides how fast you can use it — starting with a messy drawer and a row of numbered lockers — and meet the two most basic structures: arrays and lists.
The Problem in Real Life
Week nine. BlueTicket signs its biggest venue yet: a stadium with 20,000 seats. The organiser uploads the seating plan, and Anna opens the event page to check it.
The page shows a spinning wheel. And keeps spinning. After 8 seconds, the seat map finally appears. On her phone, over mobile data, it's even worse. For a small comedy club with 200 seats, the same page opens instantly.
Samantha has already seen it. "Fans won't wait eight seconds," she says. "And on Sale Day, fifty thousand of them will open this page at once."
The code is the same for both venues. Why is one fast and the other so slow?
Anna
"Just Store the Data" vs. Choosing How to Store It
Same code, different size
Code that's fast for 200 seats can be painfully slow for 20,000. Size changes everything.
Where you put things matters
How data is arranged decides how quickly you can find, add or remove things.
There's no one best way
Every way of arranging data is great at some jobs and bad at others.
Why Data Structures Exist
John asks Anna to imagine two kitchens.
The messy drawer analogy: in the first kitchen, every spice is thrown into one big drawer. To find cinnamon, you dig through everything, one jar at a time. With five jars that's fine. With two hundred, dinner is late. In the second kitchen, the spices sit on a rack in alphabetical order with labels. You go straight to C and pick up cinnamon. Same spices, same cook — the only difference is how they're arranged.
That's exactly what a data structure is: a way of organising data in memory so that the things you need to do with it are fast. Data structures don't change what data you have. They change how quickly you can find it, add to it, remove from it and go through it.
Every data structure is good at some jobs and bad at others. Choosing well means asking: what will I do with this data most often? Let's start with the two simplest structures, which almost every program uses.
- Array — a row of numbered lockers: imagine a gym with a long row of lockers, numbered 0, 1, 2, 3 and so on, side by side. If you know the number, you walk straight to it: locker 7, done — no matter whether there are 10 lockers or 10,000. That's an array: items stored next to each other in memory, each with a position number called an index (starting at 0, as in Act 07). Finding an item by its index is instant.
- The array's weakness — squeezing into the middle: now imagine you must add a new locker between number 3 and number 4, and keep the numbers in order. Everyone from locker 4 onwards has to move one place to the right. With 20,000 lockers, that's a lot of moving. Arrays are fast to read by position, but slow to insert or remove in the middle.
- Linked list — a treasure hunt: in a treasure hunt, each clue tells you where the next clue is. The clues can be anywhere in the city; they're connected only by the "next" note. A linked list works the same way: each item stores its value plus a pointer to the next item. Adding a new item in the middle is easy — just change one "next" note. But finding the 500th item means following 499 clues from the start; you can't jump straight to it.
| Job | Array (numbered lockers) | Linked list (treasure hunt) |
|---|---|---|
| Get item number 500 | Instant | Slow — follow 500 links |
| Add to the end | Usually fast | Fast |
| Insert in the middle | Slow — shift everything after it | Fast — change one link |
| Go through every item | Fast | Fast |
| Everyday use | Almost always | Inside other structures, special cases |
| Everyday thing | Data structure idea |
|---|---|
| Numbered gym lockers | Array — reach any item by its number |
| Train carriages joined one to the next | Linked list — each item points to the next |
| A stack of plates | Stack — next chapter |
| The line at a ticket counter | Queue — next chapter |
| A coat check with numbered tickets | Hash table — next chapter |
| A family tree | Tree — chapter 3 |
| A map of cities and roads | Graph — chapter 3 |
Array vs. linked list
Array
[0] A1 · [1] A2 · [2] A3 · [3] A4 — side by side
Linked list
A1 → A2 → A3 → A4 — each points to the next
Get item 3
array: jump straight there
Get item 3
list: follow A1 → A2 → A3
Insert in the middle
array: shift everything after it
Insert in the middle
list: change one "next" arrow
Array vs. list in everyday code: in JavaScript and Python, the thing called an "array" or "list" is really a dynamic array: a row of lockers that automatically grows when it's full. That's what you'll use 90% of the time. True linked lists are used inside other structures and in special cases. What matters is the trade-off: jump straight to a position (array) vs. cheap inserts in the middle (linked list).
Back to the stadium: Anna opens the seat-map code. All 20,000 seats are in one array — fine. Sold seats are in another array of about 15,000 seat IDs. For every seat on the map, the code checks: "is this seat in the sold array?" To answer, it walks through the sold array from the start, one item at a time. She doesn't know yet why that's slow — but John has gone quiet, which usually means he's spotted something.
Key Takeaway
A data structure is a way of organising data so the operations you need most are fast. An array is a row of numbered lockers: instant to reach by position, slow to insert in the middle. A linked list is a treasure hunt: easy to insert, but you must walk from the start to find anything. Always choose by asking what you'll do with the data most often.
Why This Matters
Picking the right data structure is often the difference between a page that loads in 80 milliseconds and one that takes 8 seconds — with the same computer and the same data. It isn't about being clever; it's about matching the arrangement to the job. That choice comes up in almost every feature Anna will build. (A dedicated DSA course goes much deeper; this Act gives you the mental model every developer needs.)
Arrays and lists are just the start. John grabs a stack of paper plates from the kitchen and a printout of the waitlist. "Some of the most useful structures are ones you already use every day without knowing it."