SQS Advanced Patterns for MCP Server Monitoring Pipelines: FIFO Deduplication, Visibility Timeout, Long Polling, and Batch Operations

Pattern 1 — FIFO Deduplication: MessageDeduplicationId vs ContentBasedDeduplication

Why FIFO deduplication matters for MCP probe pipelines

When a probe worker sends a result to a FIFO queue and the HTTP connection drops before the acknowledgement arrives, the worker cannot distinguish a network failure (message was never delivered) from a timeout (message was delivered, ack was lost). The safe behavior is to retry the send. Without deduplication, that retry enqueues a second copy of the same probe result — which downstream consumers process twice, potentially firing a duplicate alert, double-counting a latency sample, or inserting two identical rows into a verdict store with slightly different processing timestamps.

SQS FIFO deduplication solves this by recording a deduplication token and the arrival time for every message. Any subsequent message with the same token received within 5 minutes of the first is silently accepted (the call returns success) but not enqueued. The consumer sees only one copy. After 5 minutes, the token expires and the same token is treated as a new, distinct message.

ContentBasedDeduplication: the silent no-op

When ContentBasedDeduplication is enabled on the queue, SQS computes a SHA-256 hash of the raw message body and uses that as the deduplication token automatically — the producer does not supply a MessageDeduplicationId. This works correctly only when message bodies are fully deterministic for logically identical events.

For MCP probe payloads, this is almost never the case. A probe result body typically contains a probeRunId (UUID generated per run), a timestamp (the moment the probe completed), and a latencyMs field (which varies between runs even for the same endpoint). Because each probe result is unique at the byte level, no two sends will ever produce the same SHA-256 hash — content-based deduplication is a complete no-op. The retry protection you think you have does not exist.

Explicit MessageDeduplicationId: format and stability requirements

An explicit MessageDeduplicationId is a string up to 128 characters. For MCP probe pipelines, use a composite key derived from the logical identity of the event — not from the message content and not from a new UUID generated at send time:

// Probe result: one per endpoint per run
const deduplicationId = `${endpointId}-${probeRunId}`;
// Example: "server-abc123-run-9f4e2b"

// Alert dispatch: one per endpoint per incident
const deduplicationId = `alert-${endpointId}-${incidentId}`;
// Example: "alert-server-abc123-inc-20261029T120000Z"

// Minute-aggregated verdict: one per endpoint per minute
const minute = new Date().toISOString().slice(0, 16).replace(':', '');
const deduplicationId = `verdict-${endpointId}-${minute}`;
// Example: "verdict-server-abc123-2026-10-29T1200"

The ID must be pre-computed before the first send and held stable across all retries of the same logical event. If a retry generates a new UUID component, it produces a different ID — the second copy enqueues, and deduplication is bypassed entirely. Store the ID alongside the probe result in your local state before attempting the first send.

DLQ replay and the 5-minute window

The deduplication window is fixed at exactly 5 minutes and cannot be configured. This creates a specific constraint for DLQ replay: if you replay a message from the DLQ within 5 minutes of the original send, SQS deduplicates it — the consumer never receives the replayed message. Wait for the 5-minute window to expire before replaying DLQ messages that should re-enter the pipeline.

One exception: if the original event's semantics have changed (e.g., you're replaying to correct a downstream bug, not to retry the original processing), use a different MessageDeduplicationId for the replay to force it through the window.

Pattern 2 — Visibility Timeout: Lambda 6× Rule, ESM Auto-Extension, Heartbeat for ECS

What visibility timeout controls

When a consumer calls ReceiveMessage, SQS hides that message from all other consumers for the visibilityTimeout duration. If the consumer calls DeleteMessage before the timeout expires, processing is complete and the message is permanently removed. If the consumer crashes or the timeout expires before deletion, the message reappears in the queue with its ApproximateReceiveCount incremented by one. Once that count exceeds the DLQ's maxReceiveCount, the message is automatically sent to the DLQ instead of re-queuing.

The core risk for MCP probe pipelines is the timeout-shorter-than-processing case: if a probe result takes 45 seconds to process (writing to the verdict store, computing state-machine transitions, dispatching downstream notifications) but the queue's visibility timeout is 30 seconds, the message reappears while the original consumer is still working. A second Lambda invocation picks it up, and both process the same probe result simultaneously — a race condition on the verdict store and a potential duplicate alert.

The 6× rule for Lambda consumers

AWS's documented recommendation: set queue visibilityTimeout to at least 6× the Lambda function timeout. The safety margin accounts for Lambda internal retries on infrastructure errors, cold-start overhead, and the ESM extension mechanics described below.

import { Queue, Duration } from 'aws-cdk-lib/aws-sqs';
import { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';

const lambdaTimeout = Duration.seconds(30);

const probeQueue = new Queue(this, 'ProbeQueue', {
  visibilityTimeout: Duration.seconds(lambdaTimeout.toSeconds() * 6),  // 180s
  deadLetterQueue: { queue: dlq, maxReceiveCount: 3 },
});

probeFunction.addEventSource(new SqsEventSource(probeQueue, {
  batchSize: 1,
  // Lambda ESM handles visibility extension automatically
}));

Lambda ESM automatic extension: what it does and what it does not

When Lambda processes SQS messages via an Event Source Mapping, it automatically calls ChangeMessageVisibility on each in-flight message at approximately 2T/3 through the function timeout (where T is the function timeout in seconds). This resets the visibility timeout to the queue's configured VisibilityTimeout value — not the remaining function execution time.

Three things Lambda ESM does not do:

• It does not call ChangeMessageVisibility more than once per invocation. If your function runs longer than 2× the timeout (possible with certain async patterns or retries within the handler), the message may reappear.
• It does not extend visibility for a batch's messages individually when they take varying amounts of time — all messages in the batch receive the extension at the same 2T/3 moment.
• It does not extend visibility when the function is terminating due to a timeout error — the message reappears as soon as the original timeout expires.

Heartbeat pattern for ECS consumers

For ECS-based probe workers or Node.js polling loops that consume SQS directly, ESM is not available — visibility extension must be implemented manually. The heartbeat pattern calls ChangeMessageVisibility every visibilityTimeout/3 seconds, resetting the timeout from the current moment on each call:

import { SQSClient, ChangeMessageVisibilityCommand, DeleteMessageCommand } from '@aws-sdk/client-sqs';

const sqs = new SQSClient({});
const VISIBILITY_TIMEOUT_SEC = 60;
const HEARTBEAT_INTERVAL_SEC = 20;    // visibilityTimeout / 3

async function processWithHeartbeat(
  queueUrl: string,
  receiptHandle: string,
  work: () => Promise<void>
): Promise<void> {
  let heartbeatTimer: NodeJS.Timeout | undefined;

  const heartbeat = async () => {
    try {
      await sqs.send(new ChangeMessageVisibilityCommand({
        QueueUrl: queueUrl,
        ReceiptHandle: receiptHandle,
        VisibilityTimeout: VISIBILITY_TIMEOUT_SEC,
      }));
    } catch (err) {
      // ReceiptHandleIsInvalid = message deleted by another consumer; stop
      clearInterval(heartbeatTimer!);
    }
  };

  heartbeatTimer = setInterval(heartbeat, HEARTBEAT_INTERVAL_SEC * 1000);

  try {
    await work();
    await sqs.send(new DeleteMessageCommand({
      QueueUrl: queueUrl,
      ReceiptHandle: receiptHandle,
    }));
  } finally {
    clearInterval(heartbeatTimer);
  }
}

ReceiptHandleIsInvalid from the heartbeat call indicates the message was already deleted — either by this consumer (race between delete and the next heartbeat tick) or by another consumer after the visibility window expired. Either way, stop the heartbeat and stop processing.

Pattern 3 — Long Polling: Eliminating Empty-Response Cost

Short polling vs long polling mechanics

SQS distributes messages across multiple internal servers. A short-poll ReceiveMessage call (WaitTimeSeconds=0) samples only a subset of those servers and returns immediately with whatever messages were found — which may be zero even if messages exist on other servers. An idle probe-result queue between 60-second probe cycles generates dozens of short-poll calls per minute, each one empty, each one billed.

A long-poll call (WaitTimeSeconds=1–20) queries all SQS servers and holds the connection open until either a message arrives (returned immediately) or the wait window elapses. On an idle queue, this reduces empty responses from hundreds per minute to at most three per minute (one per 20-second window). The cost difference at scale is substantial: a single ECS consumer polling every second with short polling generates 3,600 billable requests per hour; with long polling at 20 seconds, it generates 180.

Configuration: queue attribute vs per-call override

There are two places to set WaitTimeSeconds. The queue attribute ReceiveMessageWaitTimeSeconds sets the default for all calls on the queue that do not supply an explicit value. The per-call WaitTimeSeconds parameter overrides the queue default for that specific call. Per-call takes precedence when both are set.

import { Queue, Duration } from 'aws-cdk-lib/aws-sqs';
import { SQSClient, ReceiveMessageCommand } from '@aws-sdk/client-sqs';

// Queue default: long polling
const probeQueue = new Queue(this, 'ProbeQueue', {
  receiveMessageWaitTime: Duration.seconds(20),
  visibilityTimeout: Duration.seconds(90),
});

// ECS consumer: omit WaitTimeSeconds to use queue default
const sqs = new SQSClient({
  requestHandler: new NodeHttpHandler({
    socketTimeout: 25_000,    // 25s — above 20s long-poll max
    connectionTimeout: 5_000,
  }),
});

async function pollLoop(queueUrl: string): Promise<void> {
  while (true) {
    const resp = await sqs.send(new ReceiveMessageCommand({
      QueueUrl: queueUrl,
      MaxNumberOfMessages: 10,
      AttributeNames: ['All'],
    }));

    if (!resp.Messages || resp.Messages.length === 0) continue;
    await Promise.all(resp.Messages.map(processMessage));
  }
}

Lambda ESM: no action needed

Lambda's Event Source Mapping uses WaitTimeSeconds=20 by default. This is built into the ESM implementation and is not a configurable property in CDK or CloudFormation. Lambda-triggered SQS queues generate at most ~3 empty ReceiveMessage calls per minute per polling process, which is negligible even at production scale with many concurrent Lambda executions.

When short polling is the right choice

Short polling is appropriate in exactly two situations. First, a non-blocking diagnostic check — for example, an API handler that returns approximate queue depth as part of a health check response. In this case, use GetQueueAttributes with ApproximateNumberOfMessages instead of ReceiveMessage; it is more accurate and does not consume a ReceiveMessage API call. Second, a high-throughput saturated queue where the queue is always expected to have messages: if the queue is never idle, empty responses are rare and the 20-second wait of long polling would add latency during brief inter-burst gaps.

For MCP probe pipelines, probe-result queues are idle between 60-second probe cycles. Long polling is almost always the correct choice.

Pattern 4 — Batch Operations: SendMessageBatch, DeleteMessageBatch, and reportBatchItemFailures

The cost case for batching

SQS charges per 64 KB chunk of payload per API call. A single SendMessage with a 1 KB probe-result body counts as one request. A SendMessageBatch with 10 × 1 KB bodies also counts as one request — a 10× reduction in SQS send cost. At scale, a probe cycle that monitors 500 MCP endpoints generates 500 probe results; sending them individually costs 500 API calls, batching them costs 50. The same economics apply to DeleteMessageBatch vs individual DeleteMessage calls.

The single most commonly missed default in all of SQS: ReceiveMessage returns at most 1 message unless MaxNumberOfMessages: 10 is set explicitly. A polling loop that omits this parameter is 10× less efficient than it could be.

import { SQSClient, SendMessageBatchCommand } from '@aws-sdk/client-sqs';

const sqs = new SQSClient({});

async function sendProbeResultBatch(
  queueUrl: string,
  results: ProbeResult[]
): Promise<void> {
  for (let i = 0; i < results.length; i += 10) {
    const chunk = results.slice(i, i + 10);

    const resp = await sqs.send(new SendMessageBatchCommand({
      QueueUrl: queueUrl,
      Entries: chunk.map((result, idx) => ({
        Id: `msg-${idx}`,                                          // unique within batch
        MessageBody: JSON.stringify(result),
        MessageGroupId: result.endpointId,                        // FIFO: per-endpoint ordering
        MessageDeduplicationId: `${result.endpointId}-${result.probeRunId}`,
      })),
    }));

    // Handle partial send failures
    if (resp.Failed && resp.Failed.length > 0) {
      for (const failure of resp.Failed) {
        if (failure.SenderFault) {
          // Malformed message — fix the payload before retrying
          console.error('SendMessageBatch SenderFault', failure);
        } else {
          // Service-side error — retry with exponential backoff
          scheduleRetry(chunk[parseInt(failure.Id.replace('msg-', ''))]);
        }
      }
    }
  }
}

Lambda ESM: batchSize, batching window, and FIFO limits

Lambda ESM adds two batch controls beyond the standard SQS batch API:

• batchSize: how many messages Lambda delivers per invocation. Range for standard queues: 1–10,000. Range for FIFO queues: 1–10 (FIFO cap). The default is 10.
• maximumBatchingWindowInSeconds: how long Lambda waits to accumulate a full batch before invoking, regardless of how many messages are available. Range: 0–300 seconds. Default is 0 (invoke immediately when messages arrive).

For probe-result pipelines where low latency matters — you want to process results and update verdicts as soon as they arrive — keep maximumBatchingWindowInSeconds=0. A non-zero batching window reduces Lambda invocation count at the cost of increased probe-result processing latency.

reportBatchItemFailures: the mandatory partial-failure pattern

By default, when an unhandled exception escapes a Lambda processing an SQS batch, Lambda treats the entire batch as failed. All 10 messages become visible again and are retried — including the 9 that processed successfully. This causes duplicate alert firing, duplicate verdict insertions, and wasted Lambda invocations for the 9 successful messages.

Enabling reportBatchItemFailures via CDK (reportBatchItemFailures: true on the event source) lets the Lambda handler return a structured response identifying which specific message IDs failed. Only those messages are retried:

import { SQSEvent, SQSBatchResponse, SQSBatchItemFailure } from 'aws-lambda';

export const handler = async (event: SQSEvent): Promise<SQSBatchResponse> => {
  const failures: SQSBatchItemFailure[] = [];

  for (const record of event.Records) {
    try {
      await processProbeResult(JSON.parse(record.body));
    } catch (err) {
      console.error('Failed to process', record.messageId, err);
      failures.push({ itemIdentifier: record.messageId });
      // Do NOT rethrow — let remaining messages succeed
    }
  }

  return { batchItemFailures: failures };
  // Empty array = all messages deleted (success)
  // Non-empty array = only listed messageIds retried
  // Throw = all messages retried (equivalent to pre-reportBatchItemFailures behavior)
};

Critical rules:

• Never rethrow inside the per-message loop — catch errors per record and push the messageId to the failures array.
• The itemIdentifier must match the messageId from the SQS record exactly (not the MessageDeduplicationId, not a custom ID).
• For FIFO queues, a failed item blocks all subsequent messages in the same message group until the failed item is processed or moved to the DLQ — partial failures in FIFO have a higher blast radius than in standard queues.
• Alarm on FIFO DLQ depth > 0: a message in the DLQ for a FIFO queue means all subsequent messages in that message group are silently queued behind the blocked item.

Putting it together: a production-ready SQS configuration for MCP probe pipelines

The four patterns compose into a single CDK stack configuration. Each decision has a specific reason grounded in the failure modes above:

import { Queue, QueueEncryption, Duration } from 'aws-cdk-lib/aws-sqs';
import { Function, Runtime } from 'aws-cdk-lib/aws-lambda';
import { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';

const lambdaTimeout = Duration.seconds(15);

const probeResultQueue = new Queue(this, 'ProbeResultQueue', {
  queueName: 'mcp-probe-results.fifo',
  fifo: true,
  contentBasedDeduplication: false,                       // probe payloads have probeRunId — use explicit ID
  visibilityTimeout: Duration.seconds(lambdaTimeout.toSeconds() * 6),  // 6× rule: 90s
  receiveMessageWaitTime: Duration.seconds(20),           // long polling default
  encryption: QueueEncryption.KMS_MANAGED,
  deadLetterQueue: {
    queue: probeResultDlq,
    maxReceiveCount: 3,                                   // 3 attempts before DLQ
  },
});

probeResultFunction.addEventSource(new SqsEventSource(probeResultQueue, {
  batchSize: 10,                                          // receive up to 10 per invocation
  maxBatchingWindow: Duration.seconds(0),                 // invoke immediately — latency matters
  reportBatchItemFailures: true,                          // retry only failed messages, not entire batch
}));

And the corresponding probe worker that sends to this queue with all four patterns applied:

import { SQSClient, SendMessageBatchCommand } from '@aws-sdk/client-sqs';

const sqs = new SQSClient({});

async function publishProbeResults(
  queueUrl: string,
  results: ProbeResult[]
): Promise<void> {
  for (let i = 0; i < results.length; i += 10) {
    const chunk = results.slice(i, i + 10);

    await sqs.send(new SendMessageBatchCommand({
      QueueUrl: queueUrl,
      Entries: chunk.map((r, idx) => ({
        Id: `msg-${idx}`,
        MessageBody: JSON.stringify(r),
        MessageGroupId: r.endpointId,
        // Pre-computed before first send; stable across retries
        MessageDeduplicationId: `${r.endpointId}-${r.probeRunId}`,
      })),
    }));
  }
}

This configuration eliminates the four most common SQS failure modes in MCP monitoring pipelines: duplicate probe processing from producer retries (handled by explicit deduplication ID), duplicate processing from consumer races (handled by 6× visibility timeout and ESM auto-extension), unnecessary API cost from empty polls (handled by long polling default on queue), and blast-radius amplification from batch failures (handled by reportBatchItemFailures).

Common failure modes across all four patterns