Part 6: Error Handling & Monitoring Patterns – Blog Series: Enterprise Integration Patterns with Azure

In this final post of the series, we focus on patterns that make enterprise integrations resilient, fault-tolerant, and observable. These help you design robust systems that handle exceptions gracefully and can recover or retry failed transactions with full traceability.

---

1. Circuit Breaker

✅ Scenario: Prevents continuous calls to a failing service by short-circuiting requests when failures reach a threshold.

📘 Use Case: A payment gateway is temporarily down. To avoid timeouts and cascading failures, the system halts calls for 5 minutes and serves fallback responses.

🔄 End-to-End Flow:

• Azure Function monitors call success/failure ratio.
• On failure threshold, updates a shared state (e.g., Azure App Config).
• Logic App checks status before making downstream call.

⚙️ Component Roles:

• Azure Function: Monitors failures and trips circuit.
• Azure App Configuration: Stores circuit state.
• Logic App: Checks breaker before invoking downstream API.

🛠 Azure Implementation:

• Track failure counts in Redis or Table Storage.
• Trip circuit via Azure Durable Function or App Config flag.

[Request] → [Check Circuit State] → [Call API / Return fallback]

---

2. Retry Pattern

✅ Scenario: Automatically retries failed operations based on pre-defined rules.

📘 Use Case: If a downstream tax service times out, retry up to 3 times before logging the error.

🔄 End-to-End Flow:

• Logic App attempts API call.
• If it fails, retries with exponential backoff.

⚙️ Component Roles:

• Logic App: Native retry policy.
• Function App: Implement retry with custom code or Durable Functions.

🛠 Azure Implementation:

• Use Logic App’s built-in retry configuration.
• In Functions, use Polly library or retry logic with delay.

[Logic App] → [Call Tax API with Retry Policy]

---

3. Message Expiry (TTL)

✅ Scenario: Ensures stale messages don’t clog up systems by expiring them after a time-to-live (TTL).

📘 Use Case: A flash sale order must be processed within 10 minutes. Expired orders are discarded.

🔄 End-to-End Flow:

• Order placed and sent to Service Bus with TTL.
• If unprocessed before expiry, it moves to DLQ.

⚙️ Component Roles:

• Service Bus: Handles TTL and DLQ routing.
• Logic App: Polls DLQ for monitoring.
• Cosmos DB: Stores TTL metadata.

🛠 Azure Implementation:

• Set TTL per message in Service Bus (via TimeToLive).
• Configure DLQ monitoring alert.

[Message] → [Service Bus TTL: 10 min] → [DLQ if not consumed]

---

4. Throttler

✅ Scenario: Limits message throughput to avoid overloading downstream systems.

📘 Use Case: CRM system can only process 100 leads per minute. Throttler limits batch inserts.

🔄 End-to-End Flow:

• Incoming messages are queued.
• Logic App processes them in intervals or capped volume.

⚙️ Component Roles:

• Service Bus Queue: Buffers inbound traffic.
• Logic App: Scheduled or controlled run.
• Function App: Implements rate limiting.

🛠 Azure Implementation:

• Use Service Bus + Timer trigger Logic App.
• Use Azure Functions with a concurrency limit.

[Queue] → [Timer-Based Logic App] → [CRM (100/min)]

---

5. Delayer

✅ Scenario: Delays message processing intentionally to control timing.

📘 Use Case: Delay welcome email by 10 minutes after signup to allow user profile enrichment.

🔄 End-to-End Flow:

• Signup triggers Logic App.
• Message delayed using Delay action or scheduled enqueue.

⚙️ Component Roles:

• Logic App: Adds delay.
• Service Bus: Used with ScheduledEnqueueTimeUtc.
• Email System: Final action target.

🛠 Azure Implementation:

• Use Delay or Delay Until action in Logic App.
• Or send to Service Bus with scheduled enqueue.

[Signup] → [Delay 10 min] → [Send Email]

---

6. Scheduler Agent

✅ Scenario: Executes scheduled or recurring processes like reports, notifications, or batch jobs.

📘 Use Case: Send a daily email digest at 8 AM with system activity reports.

🔄 End-to-End Flow:

• Logic App triggered by recurrence at 8 AM daily.
• Fetches data and sends digest.

⚙️ Component Roles:

• Logic App: Timer-based scheduler.
• Function App: Optional processor.
• Email API: Delivery channel.

🛠 Azure Implementation:

• Use Logic App with recurrence trigger.
• Connect to SharePoint, Blob, or SQL to fetch data.

[Timer] → [Logic App] → [Compose Digest] → [Send Email]

---

7. Store and Forward

✅ Scenario: Temporarily stores messages when downstream systems are unavailable.

📘 Use Case: When a government API is down, store compliance messages and forward once it’s back.

🔄 End-to-End Flow:

• Logic App tries API call.
• On failure, stores message in Blob or Cosmos DB.
• Another Logic App polls the store and retries delivery.

⚙️ Component Roles:

• Blob Storage / Cosmos DB: Holds messages.
• Logic App: Implements retry and resend.
• Function App: Optional custom logic.

🛠 Azure Implementation:

• Use fallback logic to persist failed message.
• Use polling or timer trigger for redelivery.

[Failure] → [Save to Blob] → [Retry App] → [API]

---

8. Redelivery

✅ Scenario: Redelivers failed messages after a delay or condition is met.

📘 Use Case: After a failed shipping request, retry every hour for up to 3 attempts.

🔄 End-to-End Flow:

• Failed message saved with retry count.
• Timer trigger checks eligibility for redelivery.

⚙️ Component Roles:

• Logic App: Manages retries.
• Storage: Keeps metadata (retry attempts, delay).
• Target System: Final destination.

🛠 Azure Implementation:

• Implement retry metadata in Table Storage.
• Redelivery logic in scheduled Logic App or Durable Function.

[Failed Msg] → [Blob + Retry Count] → [Redelivery Logic]

---

9. Idempotent Receiver

✅ Scenario: Ensures the receiver processes each message only once, even if sent multiple times.

📘 Use Case: Payment confirmation messages may be retried—ensure only one invoice is generated.

🔄 End-to-End Flow:

• Message includes unique MessageId.
• Receiver checks if it’s already processed.

⚙️ Component Roles:

• Function App: Checks deduplication ID.
• Cosmos DB: Stores processed message IDs.

🛠 Azure Implementation:

• Maintain MessageId hash table in Cosmos DB.
• Check before processing and log processed ones.

[Message] → [Check Processed] → [Skip / Process]

---

10. Correlation Identifier

✅ Scenario: Links related messages and transactions across systems.

📘 Use Case: All messages for a loan application carry the same LoanAppId to trace end-to-end.

🔄 End-to-End Flow:

• App assigns CorrelationId on request creation.
• All services pass and log this ID.

⚙️ Component Roles:

• Logic App / Function: Inject and propagate ID.
• App Insights: Trace logs with ID.

🛠 Azure Implementation:

• Set CorrelationId in headers or message body.
• Use App Insights custom dimensions to group logs.

[API] → [Function] → [Service Bus] → [Processor]
    ↳ All tagged with CorrelationId: "LN-00123"

---

11. Message Sequence

✅ Scenario: Ensures ordered processing of related message fragments.

📘 Use Case: A multi-part insurance claim arrives in chunks. Sequence ensures all parts are processed in order.

🔄 End-to-End Flow:

• Message includes SequenceNumber and GroupId.
• Receiver stores all parts, then processes in order.

⚙️ Component Roles:

• Cosmos DB / Blob: Store and group parts.
• Durable Function: Assembles and processes complete set.

🛠 Azure Implementation:

• Store fragments in Cosmos DB with sort key.
• Use Durable Functions or Logic App loops to process in order.

[Part 1/3] → [Cosmos]
[Part 2/3] → [Cosmos]
[Part 3/3] → [Cosmos]
→ [Aggregate + Process]

---

🎉 That’s a Wrap!

You’ve now seen all 65 Enterprise Integration Patterns—reimagined with Azure Integration Services like Logic Apps, Service Bus, API Management, Functions, Blob Storage, Cosmos DB, and more.