Choosing Redis Stack for vectors and cache
Why Redis Stack became the cache, vector, and document-adjacent primitive in the cluster.
Why this mattered
The early stack had separate answers for cache, metadata, and vector experiments.
This belongs in the development timeline because RPi Kubernetes is not a single feature. It is a hybrid k3s homelab with an Ubuntu control plane, four Raspberry Pi 5 workers, Cloudflare Tunnel, and a data platform made from Kafka, Flink, Redis Stack, MinIO, DataHub, Airbyte, Polaris, and observability services. The project only became useful once its infrastructure decisions were written down well enough to be repeated.
Design decision
Redis Stack simplified the mental model because RediSearch, JSON, time series, and cache semantics could be managed together.
The practical stack around this decision includes k3s, Kustomize, Helm, Strimzi Kafka, Flink Operator, Redis Stack, RAGFlow, DataHub, Airbyte, Polaris, MinIO, Prometheus, Grafana, Loki, OpenTelemetry, Cloudflare Tunnel, FastAPI, Next.js. I try to keep the interfaces small: configuration describes intent, runtime code owns behavior, and operational notes explain what a future maintainer should check first.
What I would repeat
The lesson was not that one database should do everything; it was that one operational surface can be enough for a lab stage.
The repeatable pattern is to make the boring path explicit. For this project that means clear repository boundaries, documented setup, predictable deployment commands, and enough observability to know whether the system is healthy or merely quiet.
Reader takeaway
If you are building something similar, start with the workflow you need to repeat every week. Then add only the platform pieces that make that workflow easier to recover, explain, and extend.