Login - Jit4All

Two people, on two different computers, both add a contact to this same JSON-file CRM at almost the exact same moment. One of the two new contacts ends up missing from the file afterward. Why?

Both requests read the same starting version of the file at nearly the same instant, each added their own new contact to their own in-memory copy of the array, and then each wrote their entire copy back out — whichever one wrote second completely overwrote the first one's version, including the first person's new contact, since neither request knew the other one was happening at the same time. This isn't a bug in the code from earlier lectures — it's an actual structural limit of using a single JSON file as shared storage, which is precisely why a real multi-user CRM eventually needs a database instead.

Every PHP example in this course so far has used the same pattern: read the whole file, change something in memory, write the whole file back. That pattern works perfectly for one person using the CRM at a time, which is the actual scope this course has stayed within deliberately.

A real backup matters even for a single-user JSON file, regardless of any multi-user question — a single bad write, or a syntax error introduced while hand-editing the file, can corrupt or lose every contact recorded so far, with no automatic recovery built into this simple approach.

Copying the JSON file to a second location periodically — even just by hand, copy and paste, before testing a risky change — protects against losing everything to one bad write or a typo introduced while editing the file directly.

A real database, the subject of the larger Jit-CRM course mentioned alongside this one, solves the simultaneous-write problem this lesson describes directly — it's specifically built to let many separate requests write at once without one silently overwriting another.

This lesson doesn't add a new feature to the CRM the way every earlier lecture did — it explains, honestly and specifically, the actual limit of everything built so far, and what a backup habit can and can't protect against within that limit.

<?php
$contactsFile = __DIR__ . '/contacts.json';
$backupFile = __DIR__ . '/contacts_backup.json';

// Before any risky change, copy the current file
copy($contactsFile, $backupFile);

$contacts = json_decode(file_get_contents($contactsFile), true);
// ... the rest of the page continues as in earlier lectures

$backupFile = __DIR__ . '/contacts_backup.json'; — A second file path, right next to the real one, intended to hold a recent snapshot of the data — not the live data itself.

copy($contactsFile, $backupFile); — PHP's built-in file-copy function, run before the actual read-modify-write logic — by the time anything risky happens to contacts.json, a copy of its previous state already exists separately.

What this protects against — A bad write, a corrupted file, or a mistake introduced while hand-editing the JSON directly can all be recovered from by restoring contacts_backup.json back over the broken file.

What this does NOT protect against — Two requests writing at nearly the same moment, the exact scenario in the question at the top of this lesson. A backup taken before either write started doesn't prevent the second write from overwriting the first.

This is the honest boundary of this whole course — Everything built across this course works reliably for one person using the CRM at a time. The simultaneous-write problem is the actual, specific reason a larger system needs more than a JSON file — not a vague warning, a concrete failure this lesson named directly.

Because every write in this course's pattern replaces the entire file, a script that crashes partway through writing, or a manual edit that introduces invalid JSON, can corrupt the whole file at once — there's no partial damage limited to just the most recent change.

Copying the file before testing a new feature or hand-editing the JSON costs one line of code and a fraction of a second, against the alternative of permanently losing every contact recorded if that specific edit goes wrong.

Every individual piece of PHP code across this entire course is correct on its own — the problem only appears when two separate requests happen to run at nearly the same moment, which a single-file, read-then-write approach has no built-in way to detect or prevent.

A database is specifically designed to let many requests write safely at the same time, using mechanisms this simple JSON-file approach was never built to include — naming that limit honestly here is what makes the larger Jit-CRM course's reason for existing concrete instead of abstract.

Deploying this exact JSON-file CRM for a single person to use is genuinely fine — deploying the same code assuming several people can use it at once, without understanding this lesson's limit, is the kind of mistake that quietly loses real data months later.

$contacts = json_decode(file_get_contents($contactsFile), true);
// risky new code added directly here, no backup taken first

copy($contactsFile, $backupFile);
$contacts = json_decode(file_get_contents($contactsFile), true);
// risky new code, now recoverable if something goes wrong

Ask ChatGPT to explain, in plain language, what happens if two people submit a form to this exact CRM at nearly the same moment. Then check its answer specifically against this lesson's explanation — does it correctly identify that the second write overwrites the first, or does it gloss over the actual mechanism?

Explain, in your own words, why a backup taken before a write doesn't protect against two writes happening at nearly the same time.

Write down what a real database would need to do differently to handle two simultaneous writes safely, without looking it up first.

Decide, honestly, whether this CRM as built across this course is ready for more than one person to use it at once — and explain why or why not.

Editing the JSON file by hand with no backup taken first, risking the loss of every contact if the edit introduces a syntax error.

Assuming a backup taken before a write protects against two simultaneous writes, when it only protects against one bad write being recoverable afterward.

Deploying this exact JSON-file CRM for multiple simultaneous users without understanding the specific risk this lesson describes.

Treating "it's a small CRM" as a reason this limit doesn't matter, rather than understanding it as a real, structural constraint regardless of scale.

Assuming a real database automatically solves every problem this simple approach has, without understanding specifically which problem it actually solves.

Add a basic backup step before a risky change, and explain specifically why a single JSON file used as shared storage can lose data when two writes happen nearly simultaneously — the exact, concrete reason a larger system needs a real database instead.