The Filesystem-as-Database Pattern: What Breaks When Your Primary Key Is a Path

Keying a session or workspace by its folder path is a genuinely convenient decision early on. It's already unique, it's human-readable in logs, and it saves you inventing a separate ID scheme. The convenience holds right up until a second store also keys off that string, and someone reorganizes the folder hierarchy. In a real production system, a session identifier was a literal folder path. Two independent stores both keyed off it: the primary session metadata, and a separate time-tracking log recording active work time. When the folder hierarchy was reorganized (a new top-level grouping prefix was added), the code that moved the primary metadata correctly renamed the folder and updated its own record. It did not touch the time-tracking log, because that store had no idea the rename had happened. Every reorganized session instantly read as inactive, despite having active work logged against it minutes before. Nothing was deleted, it was just orphaned under a key nothing pointed to anymore. The fix required two separate pieces, and this is the part worth internalizing: extending the rename logic to explicitly propagate into every dependent store isn't enough on its own, because you will eventually miss one. You also need an independent reconciliation pass that runs separately and heals orphaned keys after the fact, matching them back to current valid IDs by uniqueness or suffix. Rename propagation is your primary defense. Reconciliation is your backstop for when propagation inevitably has a gap you didn't anticipate. If you're auditing your own system, list every place a path-like string gets used as a lookup key, and for each one, ask specifically what happens to that store, not just the one you're actively editing, when the underlying entity moves.