11.3 API Integration & Application Caching Design (API Management, Azure Cache for Redis, CDN)

Why API Integration and Caching Design Matter on AZ-305

Microsoft groups "Recommend a solution for API integration" and "Recommend a caching solution for applications" under the same Design infrastructure solutions (30-35%) application-architecture subgroup, and this guide follows suit because the two decisions are closely linked in practice: Azure API Management's own response-cache policy is often the first caching lever an architect reaches for before standing up a dedicated cache. AZ-305 tests whether you can (1) choose the right way to expose and govern a set of APIs, and (2) choose the right caching tier for a given latency, durability, and scale requirement — rather than defaulting to "just add Redis" for every performance problem.

Core Concepts: API Management

Azure API Management (APIM) is a managed gateway that sits in front of one or many backend APIs, regardless of where those backends actually run — App Service, AKS, Functions, or even on-premises through a self-hosted gateway.

• Throttling and quotas: rate-limit and quota policies protect backends from traffic spikes and enforce fair use per subscriber.
• Subscription keys and security policies: APIM issues subscription keys per consumer and can enforce OAuth2 flows or a validate-jwt policy to check bearer tokens before a request ever reaches the backend.
• Transformation policies: rewrite headers, convert XML to JSON (or the reverse), or reshape a request/response without changing backend code.
• Products and Groups: bundle one or more APIs into a "Product" with its own visibility and terms, so public developers, partners, and internal teams can each see a different, appropriately scoped slice of the same underlying APIs.
• Versioning and revisions: version sets support breaking changes (via path, header, or query-string versioning); revisions support safe, non-breaking iteration with the ability to roll back.
• Developer Portal: a self-service portal where external or partner developers can discover APIs, read documentation, and generate their own subscription keys without opening a ticket.
• Built-in response caching: a lightweight cache policy for repeatable GET responses, avoiding the need to stand up a separate cache just for API-level caching.
• Self-hosted gateway: a containerized version of the APIM gateway that can run on-premises or in another cloud while the management plane stays in Azure — the answer whenever a hybrid or edge API-governance scenario appears.

Tiers: Consumption is serverless and billed per call, ideal for lightweight or intermittent APIs but without the SLA guarantees of dedicated capacity; Developer is for non-production evaluation only (no SLA); Basic and Standard provide fixed production capacity units; Premium adds multi-region deployment, VNet injection for full network isolation, availability-zone support, and the highest scale ceiling. A newer "v2" tier line (Basic v2, Standard v2, Premium v2) simplifies scaling for teams that do not need every classic-tier feature.

Core Concepts: Caching

Azure Cache for Redis is a managed, in-memory data store delivering sub-millisecond reads for data that would otherwise require a round trip to a database or backend service.

• Basic — a single node with no SLA; development and testing only.
• Standard — a two-node, replicated pair with automatic failover and a 99.9% SLA; the practical minimum for any production workload.
• Premium — adds clustering (for larger datasets and higher throughput), data persistence via RDB snapshots or an append-only file (AOF), VNet deployment, zone redundancy, and geo-replication for disaster recovery.
• Enterprise and Enterprise Flash — built on the Redis Enterprise engine, adding modules such as RediSearch and RedisJSON, active geo-replication, and higher availability targets than Premium.

Common uses: externalizing session state so any instance behind a load balancer can serve any user (critical the moment a web tier scales out horizontally or an instance is recycled during a deployment or autoscale event); a look-aside cache for expensive or frequently repeated database reads; distributed locks; lightweight pub/sub signaling; and leaderboard-style sorted-set data structures. Eviction policy (for example, allkeys-lru, evicting the Least Recently Used key regardless of type, versus volatile-lru, evicting only keys with an expiration set) determines what Redis discards under memory pressure, and must be chosen based on whether every key is disposable cache data or some keys must never be evicted.

A Content Delivery Network (CDN) or Azure Front Door solves a different caching problem: rather than caching per-key application data close to compute, it caches cacheable HTTP responses — images, video, scripts, and eligible API GET responses — at edge points of presence (PoPs) physically close to end users around the world, cutting both latency and origin load for globally distributed traffic. Redis and CDN are frequently used together: Redis at the application/data tier, CDN/Front Door at the network edge.

Decision Framework

• Externalize session state for a web tier that scales out or is redeployed frequently → Azure Cache for Redis, Standard tier minimum for the SLA.
• Reduce read pressure on a hot relational table without changing the database tier → Redis as a look-aside cache.
• Serve static or globally cacheable content with the lowest latency to users worldwide → Azure CDN or Front Door.
• Expose many backend microservices behind one governed entry point with throttling, security policy enforcement, and developer self-service → API Management.
• Need a hybrid or on-premises API gateway with centralized cloud-based policy management → APIM self-hosted gateway.

Exam Scenario

A company has 12 internal microservices that must be exposed to external partner developers, each partner needing its own rate limit and API key, plus a self-service portal for onboarding, and repeated product-catalog GET requests should be cached for five minutes to reduce backend load. The correct design is API Management (Standard or Premium tier depending on scale and isolation needs) with one Product per partner, subscription keys, and a response-caching policy on the catalog operation.

A second scenario: an e-commerce site's shopping-cart data must survive both autoscale events and a deployment-slot swap across multiple App Service instances, with automatic failover, while the team also wants to shave milliseconds off repeated product-catalog reads. The correct design is Azure Cache for Redis (Standard tier at minimum for the SLA, Premium if geo-replication or persistence is also required) used both for externalized session state and as a look-aside cache for the catalog reads.