MemMouse — Enterprise Memory Management

#redischallenge #devchallenge #database #ai

Redis AI Challenge: Beyond the Cache

This is a submission for the Redis AI Challenge: Beyond the Cache.

What I Built

MemMouse — a tiny control plane for managing projects → namespaces → services → policies on top of Redis. It’s a dark, glassy Next.js UI that lets you:

Create projects and namespaces, set quota/TTL/eviction, freeze/unfreeze writes.
Bind services to namespaces via key patterns, scopes, and rate limits.
Issue/rotate service tokens, and download a ready-to-use agent config for your microservice.
See a project overview (capacity, inventory, ops snapshot, top namespaces, recent events).

This is a hackathon demo, but the architecture is production-leaning: Redis is the primary metadata store, the UI is cleanly split into a control plane (Next.js API routes) and a data plane (Redis).

Demo

GitHub: https://github.com/simplizio/memmouse-next-ui
Docker Hub: docker pull simplizio/memmouse-next-ui:latest

Run with Docker Compose:

# docker-compose.yml in repo
docker compose pull
docker compose up -d
# open http://localhost:3000/projects
# (optional) seed demo data:
# curl "http://localhost:3000/api/dev/seed?force=1&drop=1"

Why it matters

Redis by itself is a blank slate. You can store anything you want inside it, but the organization of data is entirely left to the developer. Key prefixes, access policies, naming conventions — everything is tuned ad-hoc, depending on the project and team. As a result, what you get is a huge messy pile that existing monitoring tools can barely make sense of.

We propose to treat this pile as something that deserves its own service. Inside each project, data is organized into namespaces of a given size, with well-defined access for microservices.

This principle allows the process of memory management to be centralized at scale. Policies can be automated and integrated into the corporate landscape — whether it’s cloud environments or custom DevOps setups.

By applying this tool, teams gain real control and observability over their entire system. In microservice architectures, achieving that is usually a costly and error-prone effort. With our approach, life just became a little easier.

Screenshots:

Projects overview (capacity bar, counts, ops, top namespaces)

Namespace details (policy edit, usage bar, bindings)

Services (list + details with token rotate & download config)

How I Used Redis 8

I used Redis beyond caching — as the control-plane database and foundation for future streaming/events. Concretely:

Data model in Redis

Strings store JSON records:
- mm:project:{id}, mm:namespace:{projectId}:{nsId}, mm:binding:{projectId}:{nsId}:{serviceId}, mm:service:{projectId}:{serviceId}
Sets act as indexes:
- mm:idx:projects (project ids)
- mm:idx:namespaces:{projectId} (ns ids per project)
- mm:idx:bindings:{projectId}:{nsId} (service ids per ns)
- Reverse index: mm:idx:bindings_by_service:{projectId}:{serviceId} (ns ids per service)
Atomicity: updates touch both forward & reverse indexes in a single MULTI/EXEC.
Throughput: reads of many records use pipelines; admin scans use SCAN.
Durability: demo uses AOF (appendonly yes) in Docker; can flip to tmpfs for ultra-fast dev runs.

mm:project:...                  -> JSON
mm:idx:projects                 -> Set(projectId)
mm:namespace:<projId>:<nsId>    -> JSON
mm:idx:namespaces:<projId>      -> Set(nsId)
mm:binding:<projId>:<nsId>:<svcId> -> JSON
mm:idx:bindings:<projId>:<nsId> -> Set(serviceId)
mm:idx:bindings_by_service:<projId>:<svcId> -> Set(nsId)

Control plane → Agent handoff

Each service has tokens and can fetch a signed-by-us config (demo uses Bearer token check) from:

GET /api/projects/:projectId/services/:serviceId/config
Authorization: Bearer <token>

The config contains Redis endpoint, bindings (patterns, permissions, scopes, rate limits), and a telemetry target. A tiny FastAPI agent can bootstrap itself from this and enforce write patterns client-side while we work toward server-side enforcement.

Why Redis (and what’s next)

Simple, expressive primitives (Strings/Sets) make schema evolution trivial.
Fast fan-out with pipelines for listing and dashboards.
Paves the road for:
- Streams for CDC + replay/DLQ,
- Pub/Sub for live UI events,
- ACL materialization per binding (key patterns → Redis users),
- Backups via RDB/AOF snapshots per namespace.