Case study · 2026
MediaVault / Lumen
A private media system evolved around millions of records, sleeping storage, and the cost of changing a live product.
- Role
- Architect, product engineer, and operator
- Outcome
- A Go API and converged Lumen interface operating over a July 2026 snapshot of 7.3 million media items and 3.2 TB of storage.
- Capabilities
- Systems design · Product evolution · Data at scale
- Stack
- Go · SvelteKit · PostgreSQL · Docker
Sanitized walkthrough
From sleeping original to responsive catalog
01 / Ingest
Write an explicit record
The ingest boundary records metadata and schedules variants without changing the original.
02 / Derive
Keep lightweight media awake
Generated previews live separately, so browsing does not need to wake archival storage.
03 / Browse
Serve one supported interface
Lumen reads the stable catalog contract while older interface experiments remain references.
- Type
- Photo
- Date
- 2024-04-18
- Size
- 6048 × 4024
- Type
- Video
- Date
- 2024-06-02
- Size
- 3840 × 2160
- Type
- Photo
- Date
- 2025-01-12
- Size
- 4032 × 3024
Case record
The problem
A media archive is not only a gallery. It is ingestion, long-running background work, metadata contracts, access control, storage policy, recovery, and an interface that stays responsive while the underlying library keeps growing.
The constraints
- Original media lives on storage that sleeps when it is not needed.
- Generated variants must remain available without waking the archive.
- A separate scraper writes through a documented database and filesystem contract.
- Private family content must never become a public demonstration asset.
Pivotal decisions
The Go API, background worker, and scraper share explicit boundaries for database rows, storage paths, and ingest jobs. Originals remain read-only to the application; generated variants and uploads have separate storage and backup behavior.
Three experimental interfaces contributed useful ideas but multiplied operating and product costs. Lumen became the single supported interface, allowing migration effort to concentrate on one coherent experience while the older implementations remained references rather than active products.
What it demonstrates
The interesting work is not the size alone. It is changing a live system without pretending that data, storage, clients, and operators can all move at once.