This guide details a complete implementation of a nightly in‑memory caching pattern using Azure Functions on a dedicated App Service Plan with .NET 8/C#. The pattern loads full crop‑type datasets from an Azure SQL Data Warehouse each night via a timer‑triggered function, stores them in a typed, thread‑safe singleton cache, and serves all subsequent HTTP‑triggered API requests directly from that cache, eliminating per‑request database calls. The document covers cold‑start behavior on dedicated plans and how to mitigate it with a pre‑warm hosted service, the full DI registration for both isolated‑worker and web‑application models, a concrete CropDataCache implementation using ConcurrentDictionary, modernisation of legacy 2020 ADO.NET loading code to async typed records, memory‑sizing heuristics for multi‑crop datasets, the nightly timer function with partial‑failure tolerance and Azure Functions retry policy, error‑handling strategies for SQL timeouts, complete refresh failures, and empty‑cache scenarios, HTTP API design including staleness detection, response codes, and optional CDN caching headers, admin endpoints for forced refresh and cache health status, and an observability checklist (logging, custom Application Insights metrics, health‑check endpoint, alert rules). Recommendations for right‑sizing App Service tiers (B2, P1v3) based on dataset size, and best‑practice configuration snippets (host.json retry, app settings) are also provided.
Topics
Dedicated App Service Plan Cold‑Start Characteristics & Mitigation
Explains that a dedicated plan keeps the worker process alive, eliminating classic cold starts, but process restarts still clear in‑memory state; introduces a pre‑warm IHostedService to repopulate the cache on startup.