Azure Functions Production Patterns

Pathrule2 Rules • 2 Memories

Azure Functions hides server management but not delivery semantics. Triggers can retry, bindings can obscure network and serialization work, instances scale independently, and one deployment package can contain functions with very different latency and resource profiles. This pattern constrains idempotent handlers and configuration access while recording trigger, binding, scaling, and deployment ownership decisions. It differs from AWS Lambda by focusing on Azure trigger and binding contracts, host-level configuration, function-app grouping, and the operational consequences of sharing one scaled host.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

src/

functions/

Make every triggered effect idempotent

Keep invocation state isolated and dependencies bounded

host.json/

Trigger settings are part of capacity and retry design

infra/

A function app is a shared deployment and scaling boundary

Rules

Make every triggered effect idempotent/src/functionshighstrictDerive a stable operation key from the source event and return the prior outcome when Azure retries or redelivers it.

1	Queue, event, timer, and HTTP infrastructure can repeat an invocation after timeout, lock loss, ambiguous acknowledgement, or client retry. Exactly-once business effects must be created above the trigger delivery guarantee.
2
3	- Choose an event, message, schedule occurrence, or client idempotency identifier that remains stable across delivery attempts.
4	- Persist the operation state with the business transition where possible and detect completed, in-progress, and retryable-failure outcomes explicitly.
5	- Propagate the same identity to downstream queues, APIs, email, and payments rather than generating a new key at each hop.
6	- Treat timeout after an external call as ambiguous and reconcile by operation key before retrying an effect that may already have committed.
7
8	See /infra for the adjacent decision or procedure that completes this constraint.

Keep invocation state isolated and dependencies bounded/src/functionshighstrictTreat module-level objects as shared caches only when they are concurrency-safe, and pass invocation context through explicit services.

1	A warm function process can handle multiple invocations over time or concurrently depending on the host and language worker. Mutable globals can leak tenant or request state and unbounded clients can exhaust connections.
2
3	- Keep actor, tenant, payload, and per-invocation decisions in local immutable values or an explicit context object.
4	- Reuse expensive clients only when their libraries support concurrent use and their pools are bounded for the maximum host concurrency.
5	- Do not cache authorization results, mutable configuration, or user data globally without a key, expiry, invalidation, and memory bound.
6	- Ensure cancellation and timeout propagate to outbound calls so an invocation does not continue consuming dependencies after the host has abandoned its result.
7
8	See /host.json for the adjacent decision or procedure that completes this constraint.

Memories

Trigger settings are part of capacity and retry design/host.jsonReview batch size, concurrency, visibility or lock renewal, retries, and poison behavior with downstream capacity.

1	The host can deliver more concurrent work than the database or remote service can absorb. Defaults that look efficient on a queue can produce lock loss, retry storms, and connection exhaustion downstream.
2
3	- Set concurrency and batch behavior from measured execution time, dependency pools, and the largest safe in-flight work count.
4	- Keep processing time within the trigger's lock or visibility strategy and make renewal or timeout behavior observable.
5	- Use bounded retries with a poison or dead-letter destination and preserve the original operation identity and failure reason.
6	- Separate transient dependency failures from permanent validation or authorization failures so poison handling does not repeatedly attack an unrecoverable message.
7
8	See /src/functions for the rule or workflow that puts this decision into practice.

A function app is a shared deployment and scaling boundary/infraGroup functions only when they can share configuration, runtime, network, scaling, and release cadence without harming one another.

1	Functions in one app share a host process and operational envelope. Combining an HTTP latency path, memory-heavy batch, and high-volume queue consumer can create noisy-neighbor behavior and coupled deployments.
2
3	- Group by compatible runtime, permissions, network access, dependency footprint, scaling profile, and ownership rather than by a broad product name.
4	- Split functions when one workload needs independent concurrency, memory, deployment timing, or secret access.
5	- Keep host-level settings and extension configuration versioned with the deployment and test them in a representative environment.
6	- Expose per-function and host-level latency, failure, retry, throttle, and dependency signals so shared-host contention is distinguishable from handler bugs.
7
8	See /host.json for the rule or workflow that puts this decision into practice.

Why this pattern

AI agents often assume a trigger runs once, hide important I/O behind bindings, share mutable process state across invocations, or group unrelated functions into one scaling and deployment unit.

Built for Teams operating HTTP, queue, event, timer, or integration workloads on Azure Functions.

Keeps your assistant from:

Duplicating side effects when a trigger redelivers
Losing failed messages without a poison or dead-letter path
Sharing unsafe mutable state between concurrent invocations
Scaling a latency-sensitive endpoint with a resource-heavy batch function

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25