The Story
Your trip planner has users now. People log in, create trips, and on your laptop everything works. You even tested the scary case: create a trip, restart the dev server, and the trip is still there when it comes back.
Then the emails start. “I saved a trip yesterday and now it’s gone.” “My trip vanished while I was looking at it.” One user planned a whole week in Lisbon, closed the tab, came back after lunch, and found nothing.
You check the code. Trips are stored in a JSON file on the server’s disk. On your laptop, that works, because your laptop is one computer with a real disk that sticks around. Your hosting platform is nothing like that. Remember the serverless functions from Lesson 9, the on-demand workers that wake up to answer a request and then disappear? Each one gets its own short-lived scrap of disk. A trip saved by one worker gets written to a machine that’s already on its way out, and the next visit lands on a different worker that has never heard of it. The trips weren’t deleted. They were written somewhere that stopped existing.
And even if the file had survived, a second problem was waiting. Two users save at almost the exact same time. User A loads the JSON file. User B loads the same file a millisecond later. User A writes their change. User B writes their change, and stomps all over User A’s, because User B’s version didn’t include User A’s update. This one bites everywhere, even on an old-fashioned server that keeps its disk for years.
These aren’t edge cases. These are the two most common data problems in software. Data that vanishes because it lived somewhere temporary. Data that corrupts when two people write at the same time.
This lesson continues with the full course
The story intro above is free to read. The full lesson (prompts, explanations, and adapt-it exercises) requires the Ship It ($69) tier or above.
New here? Lesson 1 is free and ends with a working app.
Already bought a lower tier? Log in, you'll only pay the difference to upgrade.