Rick & Morty

Every pattern in this reference recurs in later k3s-pi5 modules. Understanding them here means you recognise them everywhere.

1. Cache-Aside Pattern

Client → API → Cache? ──hit──→ return cached
                    │
                   miss
                    │
                    ▼
              Upstream API → Store in cache → return

Where it recurs: M2 Docker Compose (.NET + Redis), M3 Sample Apps (Node.js + Postgres on k3s).

2. Rate Limiting (Fixed Window)

Request → RateLimiter middleware
              │
              ├─ within limit → controller action
              │
              └─ exceeded → 429 Too Many Requests + Retry-After header

Where it recurs: M3 Security (NetworkPolicies + RBAC), M4 Observability (Prometheus metrics on 429 counts).

3. Health + Metrics Endpoints (un-rate-limited)

GET /health   → { "status": "healthy" }           ← k8s liveness/readiness
GET /metrics  → { "requests_served": 1423, ... }   ← Prometheus scrape

Where it recurs: Every module that deploys to k3s. M4 Observability replaces the stub with real Prometheus metrics.

4. Environment-Driven Configuration

Every tunable — cache TTL, rate-limit threshold, connection string — is an environment variable. No magic numbers in code. This convention is non-negotiable and enforced across every k3s-pi5 module.

The .NET API enforces rate limiting using ASP.NET Core 8's built-in System.Threading.RateLimiting — zero extra NuGet packages.

Why it matters in this project

• Protects the upstream API. The Rick and Morty API has no auth and no documented rate limit. Being a good API citizen means self-throttling.
• Prevents runaway frontends. A buggy React effect loop could fire thousands of requests; the limiter catches it at the gateway before it reaches the DB or upstream.
• Demonstrates middleware composition. Rate limiting is early in the pipeline — it shows how ASP.NET Core middleware order matters: auth, rate limiting, caching, then the controller.

Policy design

Health and metrics endpoints are deliberately excluded — Kubernetes probes fire every 10 seconds and Prometheus scrapes every 15 seconds; throttling either would trigger false-positive pod restarts.

Full implementation: see the .NET Proxy Controller section in the README.

This tracker is the canonical source of truth for iteration progress. Completed items move to Done, and their stable content lives in the README.

This reference is the first concrete example in the k3s-pi5 learning platform. Every concept here maps to one or more curriculum modules:

Recommended learning path

1. Read this encyclopedia page — understand the architecture, decisions, and patterns.
2. Read the README — study the full code, env vars, and deployment options.
3. Follow the k3s-pi5 modules in order on the main site.
4. Return here whenever you meet a pattern you recognise — cache-aside, rate limiting, health checks — and see how it fits the larger architecture.

The Rick and Morty framing isn't just decorative — it gives every component a personality that makes the stack easier to reason about.