🧭 Slide 1 – Mastering API Control & Observability

Notes: This presentation explores a complete production-grade architecture for API rate limiting, fairness, and observability. We’ll go deep into how Redis, FastAPI, Prometheus, Grafana, and Redis Commander come together as a cohesive stack to create an intelligent, self-regulating system. By the end, you’ll understand not just how to prevent overloads but also how to see, measure, and adapt to system behavior in real time.

⚙️ Slide 2 – The Problem: Load Control & Visibility

Notes: APIs often look stable during normal usage — until someone overloads an endpoint. Without intelligent rate control, one client can degrade the experience for everyone else. This architecture enforces fairness and provides real-time visibility into who’s consuming your resources and how effectively you’re throttling requests. The end goal: keep your API reliable, fair, and scalable under any traffic pattern.

🧩 Slide 3 – The Stack (5 Core Components)

Notes:

1. Redis acts as the atomic control engine — instant key-value decisions at in-memory speed.
2. FastAPI is our modern async web framework — lightweight, Pythonic, and perfect for high concurrency.
3. Prometheus collects and stores metrics in time series format.
4. Grafana turns that raw Prometheus data into visual dashboards and alerts.
5. Redis Commander is a friendly web UI for inspecting what’s happening inside Redis in real time. Together, they form a lab-grade architecture for both control and insight.

🧱 Slide 4 – Containerized Lab: Key Ports

Notes: Everything runs inside Docker Compose, ensuring reproducibility and easy teardown.

• FastAPI (8001) handles API requests.
• Redis (6379) stores atomic counters and TTLs.
• Prometheus (9090) scrapes metrics.
• Grafana (3000) visualizes them.
• Redis Commander (8081) lets you watch keys update live. Each container depends on the previous one to ensure clean startup sequencing.

🚦 Slide 5 – Why Redis is the Traffic Cop

Notes: Redis isn’t just a cache — it’s the enforcer of fairness. It handles every request decision atomically — thanks to its single-threaded nature. Every command executes in total isolation, preventing race conditions. It also supports TTL (Time To Live), allowing automatic key expiry — perfect for rate-limit windows. Redis becomes the decision-making brain behind every “allow” or “block” in the system.

⚡ Slide 6 – Async Redis Client with FastAPI

Notes: FastAPI is asynchronous, and to fully exploit that, we must use redis.asyncio. If we used a synchronous client, every call to Redis would block the entire event loop — destroying concurrency. With async Redis, requests yield control while waiting, allowing FastAPI to process hundreds of other connections in parallel. This is what makes the system scalable and responsive even under heavy load.

🔒 Slide 7 – Atomicity Patterns in Redis

Notes: Redis guarantees atomic operations:

1. Single-key atomicity: INCR or DECR updates happen as a single step.
2. Multi-key atomicity: WATCH + MULTI + EXEC ensures consistent multi-key operations without locks.
3. Server-side atomicity: Lua scripts let us ship complex “check-then-act” logic directly into Redis — reducing latency and ensuring no interference between concurrent clients. These capabilities make Redis ideal for precise rate control.

🔑 Slide 8 – Rate Limiting: Composite Key

Notes: Rate limits must balance fairness and prevent evasion.

• Limiting only by API key lets attackers rotate IPs to bypass limits.
• Limiting only by IP punishes shared networks unfairly. The composite key — X-API-KEY.Client-IP — solves both. Each unique combination has its own independent counter. Anonymous users use anon.Client-IP, providing fair IP-based protection even for unauthenticated traffic.

⏲️ Slide 9 – Strategy 1: Fixed Window

Notes: The simplest algorithm — count requests in a fixed time slice (e.g., 10 seconds).

• Use INCR to increase request count.
• Set EXPIRE for automatic reset. Pros: trivial to implement and very fast. Cons: boundary bursts — users can send double the allowed requests by hitting both sides of the reset boundary (e.g., 9.9s + 10.1s). Good for basic protection but not fair under all traffic patterns.

📈 Slide 10 – Strategy 2: Sliding Window

Notes: A more accurate and fairer approach. Redis ZSETs store each request timestamp as a scored element. Steps per request:

1. Remove timestamps older than the rolling window (ZREMRANGEBYSCORE).
2. Add the current timestamp (ZADD).
3. Count active timestamps (ZCARD). If the count exceeds the limit → block (429). It uses more memory but smooths out bursts perfectly — making it ideal for high-traffic APIs.

💧 Slide 11 – Strategy 3: Token Bucket

Notes: Models capacity and refill rate rather than counting. Each key has:

• capacity (max tokens)
• refill_rate (tokens/sec)
• cost (tokens/request) When a request arrives:
• Redis Lua script refills tokens based on elapsed time.
• If enough tokens exist → consume and allow.
• If not → deny. Allows bursts but enforces a stable long-term rate. Perfect for tiered APIs (Free, Pro, Enterprise).

🧮 Slide 12 – Observability with Prometheus

Notes: Prometheus pulls metrics from the FastAPI /metrics endpoint. Scrapes occur every 5 seconds (configurable). Metrics include:

• request_total: counts requests by endpoint, strategy, and status (200 vs 429).
• rate_limited_total: counts blocked requests by strategy.
• request_latency_seconds: a histogram for latency distribution, enabling P50, P90, and P99 percentile calculations. These reveal both control efficiency and performance overhead.

📊 Slide 13 – Grafana Dashboards & PromQL

Notes: Grafana visualizes Prometheus data in near-real-time dashboards. Auto-provisioned setup connects to Prometheus out-of-the-box. Panels include:

• Requests by Endpoint & Status: See allowed (green) vs blocked (red) traffic live.
• Total Requests / Rate-Limited Count: Global summary of load.
• Latency Quantiles (P50/P90/P99): Understand user experience at different percentiles. PromQL examples power these charts:
• sum(rate(request_total{status="200"}[1m])) by (endpoint)
• histogram_quantile(0.99, sum(rate(request_latency_seconds_bucket[5m])) by (endpoint, le)))

🧠 Slide 14 – Layered View (Recap)

Notes: A four-layer architecture emerges:

• Control Layer (Redis): Atomicity, rate limits, Lua scripts.
• Application Layer (FastAPI): Routes, business logic, metrics exposure.
• Metrics Layer (Prometheus): Time-series history and labeled tracking.
• Insight Layer (Grafana): Dashboards, PromQL queries, and alerts. Each layer complements the others — forming a closed loop from control → visibility → insight → action.

🚀 Slide 15 – Next Steps: Automation & Dynamic Tiers

Notes: Two powerful extensions to the core stack:

1. Automation

• Use Prometheus Alertmanager or Grafana alerts to detect anomalies (e.g., spikes in rate_limited_total).
• Automatically notify teams or trigger scripts that block offenders or reduce their refill rate.

2. Dynamic Tiers

• Integrate with user authentication and subscription systems.
• Dynamically pass different token bucket parameters per tier (Free, Bronze, Gold).
• Monetize rate limits safely using the same Redis-Lua foundation.

🧪 Slide 16 – Hands-On Exercise

Notes: To cement understanding, try the lab yourself:

1. Run the provided docker-compose.yml.
2. Open FastAPI (port 8001) and Redis Commander (8081) side-by-side. Watch counters update as you hit the API.
3. Open Grafana (3000) to see live graphs of throughput, blocked requests, and latency. Experiment by modifying window durations or token bucket parameters and watch Grafana respond in real time.

Would you like me to:

• ✅ Embed these as actual PowerPoint “Notes” under each slide (so they show in Presenter View)?
• or 📄 Export them as a separate PDF “Presenter Guide” with slide thumbnails + notes beneath each?