API Integration & Caching

API and caching design

Simple explanation

API Management is the front door to your APIs. It handles authentication, rate limiting, transformation, and analytics — so your backend services focus on business logic.

Caching is the shortcut. Instead of computing the same result 1,000 times, compute it once and cache the answer. Azure Cache for Redis handles in-memory caching. Azure CDN and Front Door cache content at edge locations close to users.

Azure API Management

Feature	What It Does
API Gateway	Single entry point — routes requests to backend services
Policies	Transform requests/responses, authenticate, rate-limit, cache, validate
Developer Portal	Self-service portal for API consumers (docs, try-it, API keys)
Products	Group APIs with usage quotas and terms — publish to specific audiences
Analytics	Request volume, latency, errors, geographic distribution

APIM tiers

API Management Tiers
Factor	Consumption	Developer	Standard v2	Premium v2
Scaling	Serverless (auto)	1 unit	Configurable units	Configurable units
SLA	99.95%	No SLA	99.95%	99.99%
VNet integration	No	Yes	Outbound VNet integration	VNet injection (full inbound+outbound)
Multi-region	No	No	No	No (classic Premium required)
Self-hosted gateway	No	Yes (for dev/test)	No	No
Cost	Pay per call	~$50/mo	~$300+/mo	~$3,000+/mo
Best for	Low traffic, serverless APIs	Dev/test	Production single-region	Enterprise, VNet isolation

🚀 Marcus’s APIM design: NovaSaaS exposes APIs to partners:

Standard v2 tier with outbound VNet integration
OAuth 2.0 validation policy — validates JWT tokens from partner Entra ID apps
Rate limiting — 1,000 requests/minute per partner
Response caching policy — cache GET responses for 5 minutes (reduces backend load by 80%)

Azure Cache for Redis

Use Case	Description	Pattern
Data caching	Cache database query results	App checks cache first → hit = return cached, miss = query DB + cache result
Session state	Store user sessions across web farm	Centralised session store — all instances share session data
Message broker	Lightweight pub/sub	Redis pub/sub for real-time notifications
Distributed lock	Prevent concurrent processing	Redis SETNX for cross-instance coordination

Redis tiers

Tier	Memory	HA	Best For
Basic	250 MB - 53 GB	No SLA, no replication	Dev/test
Standard	250 MB - 53 GB	Primary + replica (99.9% SLA)	Production caching
Premium	6 GB - 120 GB	Clustering, geo-replication, VNet, persistence	Enterprise, high throughput
Enterprise	12 GB - 2 TB	Redis Enterprise features, active geo-replication	Mission-critical, multi-region

CDN and Front Door

Azure CDN vs Azure Front Door
Factor	Azure CDN	Azure Front Door
Primary purpose	Static content caching at edge	Global load balancing + WAF + caching
Routing	Simple (origin-based)	Advanced (URL path, header, geography)
WAF	No — use Front Door for WAF	Full WAF with custom rules and bot protection
SSL offloading	Yes	Yes + custom domain certificates
Caching	Static content (images, CSS, JS)	Static + dynamic content caching
Health probes	Yes	Yes + fast failover
Best for	Static websites, media delivery	Global applications needing WAF + routing + caching

🏦 Elena’s edge design:

Front Door Premium with WAF protecting all customer-facing APIs
Custom WAF rules blocking known attack patterns and geo-restricting to operating countries
Caching for API responses that don’t change per-user (product catalogs, exchange rates)
Private Link origin connection — backend services never exposed to the internet

Knowledge check

Question

When should you recommend Azure Front Door over Azure CDN?

Click or press Enter to reveal answer

Answer

When you need: global load balancing (not just caching), WAF with custom rules, advanced URL-based routing, or fast failover between backend origins. CDN is simpler and cheaper for static content delivery. Front Door is the full edge platform for global applications.

Click to flip back

Question

What's the most common caching pattern with Azure Cache for Redis?

Click or press Enter to reveal answer

Answer

Cache-aside pattern: Application checks cache first. On cache hit, return cached data. On cache miss, query the database, store result in cache (with TTL), and return data. This reduces database load by serving repeat queries from memory.

Click to flip back

Question

What are the main cache invalidation strategies and when to use each?

Click or press Enter to reveal answer

Answer

TTL-based: set an expiry time — simplest, accepts some staleness. Event-driven: invalidate cache when source data changes (via Event Grid or change notifications) — most accurate. Write-through: update cache and database simultaneously — ensures consistency but adds write latency. For most apps, TTL with event-driven invalidation for critical data is the balanced approach.

Click to flip back

Knowledge Check

🚀 NovaSaaS exposes APIs to 50 partner companies. Each partner needs rate limiting, JWT validation, and the ability to discover APIs through a self-service portal. Which service should Marcus use?

Knowledge Check

🏦 Elena's trading platform queries Azure SQL for account balances on every transaction. The database is overloaded at 90% DTU during peak hours. Balances change frequently and stale data could cause overdrafts. Which caching strategy should Elena recommend?

Next up: Configuration and deployment automation — App Configuration & Automated Deployment.