Example, customer-style applications built to exercise Redis Search on Disk (MS2) during the bug bash. Each application drives realistic ingestion and query patterns at scale against on-disk indexes, so we get broad coverage of the surface and shake out bugs.
Use-case catalog (source of truth): the internal design doc Redis Search on Disk — MS2 — Use-cases.
On-disk indexes exist for datasets that don't fit in RAM, so lean on scale. The supported disk field types are TEXT, TAG, and VECTOR — build the applications around those.
<use-case>/ one folder per use case
├── README.md describes the use case (domain, schema, queries, stress axes)
├── _TEMPLATE/ starting point — copy it and rename to your GitHub username
│ └── README.md
└── <your-github-username>/ your implementation lives here — one folder per contributor
└── ...
README.md this file
Several people can work the same use case — each contributor gets their own folder, so there are no collisions.
- Pick a use case below (or add a new one — mirror it in the use-case doc and add a folder here following the same layout).
- Claim it in the internal Redis Search on Disk — MS2 — Use-cases doc: add yourself as an Owner and flip the status to IN PROGRESS.
- Copy that use case's
_TEMPLATE/folder and rename the copy to your GitHub username. - Build your app inside that folder and fill in its
README.md. - Log findings — link any bugs/tickets you open in your README, and flip your status in the use-case doc to DONE when you're finished.