The Story
Your trip planner has users now. People log in, create trips, and everything seems fine. For a while.
Then you push an update. Your hosting platform redeploys the app. It takes about thirty seconds. When the app comes back up, three users email you with the same message: “All my trips are gone.”
You check the code. Trips are stored in a JSON file on the server’s disk. When the server redeployed, it got a fresh copy of your code — which includes a fresh, empty JSON file. Every trip anyone ever created just vanished.
But it gets worse. Before the redeploy, you’d been noticing a weirder problem. Sometimes a user would save a trip and it would show up fine. But an hour later it would be slightly different — overwritten with someone else’s data. What was happening? Two users were saving 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.
These aren’t edge cases. These are the two most common data problems in software. Data that disappears when the server restarts. Data that corrupts when two people write at the same time.
The fix for both is the same thing, and it’s one of the most important concepts in all of software: a database.
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.