A subscription app serves the same product-plan catalog to thousands of users while each customer stores account-specific preferences. Engineers propose placing catalog records and account preferences together in a cache to avoid database calls, then deploying configuration flags by editing files on running web servers. The solution is fast until a cached price changes and several instances serve different values. The architecture needs to separate cached read models, authoritative transaction state, configuration distribution and controlled application deployment.
Microsoft AZ-305 tests application architecture, caching, configuration management and automated deployment. The existing compute platform selection asks where the application runs. This guide asks how multiple instances share safe data and settings while being replaced, scaled or rolled back. It also accounts for Azure’s 2026 Redis service transition: new platform decisions should examine Azure Managed Redis rather than blindly choosing a retiring Azure Cache for Redis tier.
Identify what may be cached and how stale it may become
List expensive, frequently repeated reads and classify their required freshness. Public catalog images and stable reference tables are usually easier to cache than inventory reservations, medical records or payment balances. A cache is a derived store; the source of truth must remain explicit. If a cache entry is lost, the application should know how to rebuild it without inventing customer data or bypassing authorization.
Record a cache key strategy that accounts for language, tenant, product version and authorization context. A shared key such as user-profile can leak one customer’s data to another, even when the original database query was secure. If the same representation is safe for all users, avoid unnecessarily multiplying entries by user identity. Design the keys from the precise representation boundary rather than convenience.
Prefer current managed Redis options with lifecycle awareness
Azure Managed Redis provides a managed Redis-based caching direction for supported workloads. Microsoft’s Azure Cache for Redis retirement FAQ states that the legacy Basic, Standard and Premium tiers retire September 30, 2028, and Enterprise/Enterprise Flash retire March 31, 2027. It recommends moving to Azure Managed Redis. The exact timeline matters: existing caches may continue operating for a period, but new architecture should not assume the retiring service is a timeless baseline.
Choose cache service, tier, replication and deployment features based on current product capabilities, supported Regions, cost and availability needs. A cache that is faster in a benchmark may still violate the application’s resilience target if failover or reconnection behavior was not tested. Keep migration options and replacement endpoints in the operating plan for any existing retiring tier.
Distinguish performance from correctness
Cache-aside reads commonly query the cache and populate it on a miss. They can reduce repeated database load when data changes slowly. But a missing key, stale entry or cache service outage must have defined fallback behavior. For strictly consistent billing or account state, reading the primary database may be necessary; a stale discount code or balance is a business bug even if it returns in two milliseconds.
Use expiration, explicit invalidation, versioned keys or event-driven updates according to the write pattern. A key with a very long TTL can become obsolete after a price change. A very short TTL can create repeated backend reads that erase the performance gain. Pick freshness from a business requirement, not a generic value from a sample tutorial.
Prevent cache stampedes under peak demand
If thousands of clients request one popular item just after the key expires, they can all miss the cache simultaneously and overload the database. Apply appropriate request coalescing, staggered expiration or rate limiting when required. Consider background refresh and circuit-breaker behavior for expensive data. The number of cache hits alone does not prove the backend is protected if a small set of expensive misses dominates database CPU.
Test the failure state deliberately. Temporarily remove one popular key under synthetic traffic, monitor database read pressure and user latency, and observe whether clients continue to complete their operations. If the fallback overloads the only database writer, the cache has become a hidden availability dependency instead of a performance optimization.
Use App Configuration for distributed application settings
Azure App Configuration can centralize supported configuration values and feature flags for applications, reducing the need for manually edited files on individual servers. The App Configuration overview describes its role and feature-management patterns. Separate configuration values from secrets: credentials and keys belong in an appropriate secret-management boundary such as Key Vault, accessed through controlled identity when supported.
Plan refresh cadence, labels, environment separation and feature flag ownership. A new flag should have a documented default, rollout audience and rollback plan. If three application instances refresh at different times, code must tolerate that temporary configuration divergence or deployment must coordinate a version boundary. Configuration centralization makes change observable; it does not guarantee instant global consistency.
Make identity and network access least privileged
Application instances should use managed identities or supported scoped authentication for Redis, App Configuration and Key Vault where applicable. Avoid embedding broad access keys into source control or container images. Restrict the network path with private connectivity where supported and justified, but test name resolution and certificate trust because a private endpoint that resolves incorrectly is still unavailable to the client.
The AZ-305 governance and RBAC specialist provides authorization context. Apply separate permissions to read production configuration, change feature flags, rotate secrets and administer cache instances. One compromise in a public-facing app should not automatically permit changing global flags or deleting a cache resource.
Use infrastructure as code for repeatable releases
Bicep or other supported declarative deployment methods can express infrastructure configuration in version-controlled files. App code releases should carry a clear relationship to infrastructure and configuration changes. Review who can apply production changes, how policy is enforced and how the deployment detects drift. A manual console fix that is not recorded in the deployment source may disappear on the next automated release.
For application releases, use a strategy such as deployment slots, staged traffic, canary rollout or blue/green where supported by the selected compute platform. Verify essential requests and health indicators before increasing exposure. A new cache key format may be incompatible with old app versions running during a staged deployment; versioned keys or backward-compatible readers can make the transition safe.
Observe staleness and rollout success as operational signals
Measure cache hit ratio, eviction, memory pressure, connection errors, backend query demand, and customer-visible latency. Track configuration version, flag assignments and deployment identity in logs so engineers can determine whether a failed request ran old or new behavior. Too many unique feature variants make testing expensive and may increase incident confusion; retire obsolete flags once the decision is complete.
A cost model should include cache capacity, networking, operational telemetry, configuration reads, idle environments and any charge associated with higher availability. Removing a cache may increase database costs enough to outweigh its monthly price; keeping a large cache full of unused data can be wasteful. Compare end-to-end cost per successful transaction rather than only cache service fees.
Test a controlled release and a cache outage
Build a tiny subscription catalog with synthetic users. Change one shared price, invalidate or version the cache key, and verify all users eventually receive the correct new value within the agreed window. Then run an unauthorized tenant request and prove no cached object crosses the tenant boundary. Roll out a feature flag to a small test cohort, observe results, and roll it back without redeploying code. Finally, simulate a cache outage and verify bounded fallback does not overwhelm the database.
An AZ-305 recommendation should identify the authoritative store, cached representations, invalidation method, distributed configuration contract, rollout controls and recovery path. A well-architected application remains correct when caches are empty, configuration changes mid-deployment, or one instance rolls back; it does not rely on every cache hit and feature flag arriving in perfect order.