Cache Service

Service: cache-service (cache-api) · Ports: 8080 (HTTP), 9090 (gRPC)

cache-service gives every KubeOpera service a shared, fast cache without each one needing its own Redis client. It wraps Redis behind a small HTTP and gRPC API: get, set, delete and an atomic counter used for rate limiting.

Why it exists

Several services need shared, short-lived state — auth-service's sign-in rate limits, cached lookups in kubeopera-api and others. Centralizing it means:

• one place to configure, secure and scale Redis;
• services depend on a tiny API, not a Redis client;
• the same operations are available over HTTP (simple) and gRPC (fast, for high-frequency callers).

Operations

Operation	Description
Get / set / delete	Store a value by key, with an optional TTL.
Increment with expiry	Atomically increment a counter and reset its TTL — a sliding-window counter, the building block for rate limits.

Security

Every cache route requires a service token (or the cache's API key for legacy callers); /healthz is public. Keys are namespaced per calling service, so one service can't read or reset another's data.

REST API

Method	Path	Description
GET	/cache/{key}	Get a value.
POST	/cache	Set a value ({ "key", "value", "ttl_seconds" }).
DELETE	/cache/{key}	Delete a value.
POST	/cache/{key}/increment	Increment a counter and reset its TTL.
GET	/healthz	Health check.

Configuration

Variable	Default	Description
REDIS_ADDR	redis:6379	Redis address.
REDIS_PASS	—	Redis password.
REDIS_DB	0	Redis database number.
CACHE_BACKEND	redis	redis, or memory for local development only.
HTTP_PORT / GRPC_PORT	8080 / 9090	Ports.

note

Use the memory backend only on a laptop: its counters don't survive restarts or apply across replicas, so rate limits wouldn't hold in production.