Memory hook: Messages need settlement, events need routing, functions need bounded retry-safe execution.
Must remember
- Service Bus queues deliver work to competing consumers; topics/subscriptions fan out with subscription filters. Peek-lock processing needs completion, abandonment/dead-lettering or lock renewal as appropriate. Duplicate detection and sessions solve specific deduplication/ordering needs; still make side effects idempotent.
- Inspect dead-letter reason/description, fix the cause and replay deliberately. Poison messages must not cycle forever. A lock timeout can cause redelivery after the handler has already changed an external system.
- Event Grid routes supported/custom events with filtering, retry and dead-letter configuration. Validate event schemas and subscription handshakes; do not treat an event notification as a durable authoritative database record by itself.
- Functions triggers start execution; bindings connect supported input/output services. Build HTTP APIs with authentication, validation and useful error responses. Hosting plan affects scale, execution, networking and cost; deployment settings and runtime versions must match the code.
- Key Vault holds secrets/keys/certificates with controlled retrieval/rotation. App Configuration holds application settings and feature flags; it is not simply another password store. Use managed identities and scoped roles rather than embedded keys.
- OpenTelemetry propagates trace context across HTTP, queues and functions when instrumented correctly. Correlate logs with spans; use KQL to inspect dependency failures and latency. Redact secrets and payloads, monitor retries/locks/lag and distinguish invalid input from transient service failures.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Durable business work with competing workers | Service Bus queue. |
| Route notifications to interested handlers | Event Grid. |
| One slow operation risks message-lock expiry | Renew appropriately or redesign bounded processing with idempotency. |
Traps
- Completing a message before durable success can lose work.
- A binding simplifies code but does not remove permissions or failure semantics.
- Retrying every exception can duplicate actions and hide permanent errors.
Active recall
1. What happens when a locked message is not settled before its lock expires?
It can become available for redelivery according to service behaviour.
2. Why inspect DLQ reasons before replay?
Otherwise the same poison condition may fail repeatedly.
3. What differs between a trigger and an input binding?
The trigger initiates execution; a binding supplies an integration/data connection for that invocation.
4. Why propagate trace context through messages?
To connect asynchronous producer/consumer work into a diagnosable operation.
5. What should a function do before retrying an ambiguous write?
Use an operation/idempotency key to reconcile whether the side effect already succeeded.