osFoundry / Platform
KV-Speicher pro App
Redis-kompatibler KV mit TTLs. Sitzungen, Caches, Zähler – auf Ihre App zugeschnitten.
Was es ist
Der Per-App-KV-Store gibt jeder App, die du innerhalb von osFoundry baust, ihr eigenes Redis-kompatibles Key-Value-Backend. Wer Redis kennt, kennt auch das hier: einen Key setzen, ihn wieder auslesen, einen Zähler hochzählen, ein Time-to-Live anhängen, damit der Eintrag von selbst abläuft. Jede App erhält ihren eigenen isolierten Namespace, sodass die Session-Keys einer App nie mit den Cache-Einträgen einer anderen kollidieren. Es gibt keinen separaten Redis-Server, den du bereitstellen, absichern oder am Leben halten musst: Der Store ist Teil der App-Laufzeit und auf die App zugeschnitten, die ihn nutzt.
Das TTL ist der eigentliche Sinn eines KV-Stores, und es verhält sich genau so, wie du es erwartest. Schreib ein Session-Token mit 30 Minuten Ablauf, und es verschwindet, sobald das Fenster schließt; cache eine teure API-Antwort für fünf Minuten und lass sie sich selbst erneuern; halte ein kurzlebiges Lock oder ein Rate-Limit-Fenster, das sich automatisch leert. Weil Keys ohne Aufräum-Job ablaufen, speicherst du flüchtigen Zustand, ohne Müll anzusammeln. Auch Zähler sind vollwertig: Atomares Inkrementieren und Dekrementieren liefert dir Aufrufzahlen, Kontingent-Tracking und einfache Sequenznummern ohne Read-Modify-Write-Races.
Das passt zur Gestalt von osFoundry als Bring-your-own-Key-Desktop-Workspace, in dem Chat, Agenten, Apps, Code, Wissen und Daten an einem Ort liegen. Der KV-Store ist die schnelle, flüchtige Ebene, die neben den übrigen Daten deiner App sitzt: Nutze ihn für alles, was heiß, klein und kurzlebig ist, und halte dauerhafte Datensätze anderswo. Redis-Kompatibel zu sein heißt, dass mentales Modell und Befehlsvokabular von allem übernommen werden, was du zuvor gebaut hast, sodass du keine neue API lernst, um Sessions und Caches zum Laufen zu bringen.
Wichtige Funktionen
- Redis-kompatible Key-Value-API: GET, SET, INCR, EXPIRE und die Befehle, die du schon kennst, kein neuer Client zum Lernen
- TTL pro Key, damit Sessions, Cache-Einträge und Locks von selbst ablaufen, ganz ohne Aufräum-Job
- Isolierter Namespace pro App: Die Keys jeder App sind auf diese App beschränkt und kollidieren nie mit denen einer anderen
- Atomare Zähler per Inkrement und Dekrement für Aufrufzahlen, Kontingente und Rate-Limit-Fenster ohne Race Conditions
- Läuft als Teil der App innerhalb von osFoundry: nichts bereitzustellen, und der Store ist auf die nutzende App zugeschnitten
Anwendungsfälle
- App-Entwickler: Login-Sessions mit gleitendem TTL speichern, damit Nutzer angemeldet bleiben und veraltete Tokens sich selbst löschen
- Backend-Entwickler: langsame Antworten von Drittanbieter-APIs für ein paar Minuten cachen, um Latenz und wiederholte Aufrufe zu senken
- Autor von Agenten-Tooling: einen Rate-Limit-Zähler pro Minute halten, der sich über einen ablaufenden Key automatisch zurücksetzt
Häufig gestellte Fragen
Ist es wirklich Redis oder nur Redis-ähnlich?
Es ist Redis-kompatibel, das heißt, es spricht dieselben Key-Value-Befehle und dieselbe Semantik, die du bereits nutzt: SET mit Ablauf, GET, INCR, DEL, sodass sich bestehende Gewohnheiten und Code-Muster direkt übertragen. Der Vorteil: Es ist in die App-Laufzeit von osFoundry eingebaut, du musst also keinen separaten Redis-Server aufsetzen oder absichern, um es zu bekommen.
Was gehört in den KV-Store und was in eine echte Datenbank?
Nutze KV für heißen, kleinen, kurzlebigen Zustand: Sessions, Caches, Zähler, Rate-Limit-Fenster und Locks, alles, dessen Ablauf dir recht ist. Dauerhafte Datensätze, die überleben und abfragbar sein müssen, gehören in eine richtige Datenbank. Der KV-Store ist die schnelle, flüchtige Ebene, nicht dein System of Record.
Laufen Keys über TTL automatisch ab?
Ja. Wenn du einem Key ein Time-to-Live gibst, wird er entfernt, sobald dieses Fenster verstrichen ist, ohne Aufräum-Job auf deiner Seite. Genau das macht ihn ideal für Sessions und Caches: Daten, die temporär sein sollen, löschen sich selbst, statt sich anzuhäufen.