Not a beta blocker. Tracking a known, deferred path to scale the data layer as real usage grows. The trigger to act is load-test results / actual demand, not now.
GhostKey is a low-frequency app (check-ins are roughly monthly), so the current setup has plenty of headroom for the founding-user stage, and vertical scaling extends that further. This issue just records the direction so we act deliberately rather than reactively.
Staged direction (high level)
- Measure first. Establish the real ceiling under load before changing anything.
- Scale vertically while it's enough — a config change, no rearchitecting.
- When growth warrants: move the datastore to a client/server database and separate the long-running background work from the request-serving tier so the latter can scale horizontally. (Detailed design notes are kept out-of-band.)
- Later, if ever needed: higher-availability / multi-region topology.
Sequencing note: the deeper changes should come after the security audit (#183), so we're not auditing code we're about to rewrite.
Done when
We have a measured headroom figure and are either comfortably within it, or the datastore/tier-split work has shipped and re-measured against the target.
Not a beta blocker. Tracking a known, deferred path to scale the data layer as real usage grows. The trigger to act is load-test results / actual demand, not now.
GhostKey is a low-frequency app (check-ins are roughly monthly), so the current setup has plenty of headroom for the founding-user stage, and vertical scaling extends that further. This issue just records the direction so we act deliberately rather than reactively.
Staged direction (high level)
Sequencing note: the deeper changes should come after the security audit (#183), so we're not auditing code we're about to rewrite.
Done when
We have a measured headroom figure and are either comfortably within it, or the datastore/tier-split work has shipped and re-measured against the target.