SNS FIFO Topics for MCP Servers — Ordered Event Delivery, MessageGroupId, Deduplication

FIFO vs Standard SNS topics

MessageGroupId: ordering scope for MCP endpoints

Every message published to a FIFO topic requires a MessageGroupId. Messages with the same GroupId are delivered in the exact order they were published. Choose the granularity of your GroupId to match the ordering requirement:

Blocking within a group: If a consumer fails to process message N, the FIFO queue holds all subsequent messages in the same group until N is either processed or moved to the DLQ. For MCP monitoring workloads, per-endpoint groups contain blast radius to a single endpoint — one flaky endpoint does not block status updates for thousands of others.

// Publish with per-endpoint MessageGroupId
const client = new SNSClient({ region: "us-east-1" });

await client.send(new PublishCommand({
  TopicArn: "arn:aws:sns:us-east-1:123456789012:mcp-status.fifo",
  MessageGroupId: `endpoint-${endpointId}`,     // scopes ordering per endpoint
  MessageDeduplicationId: `${endpointId}-${probeRunId}`,  // explicit dedup ID
  Message: JSON.stringify({
    endpointId,
    status: "degraded",
    probeRunId,
    probeAt: new Date().toISOString(),
    latencyMs: 4820,
  }),
  MessageAttributes: {
    status: { DataType: "String", StringValue: "degraded" },
    region: { DataType: "String", StringValue: "us-east-1" },
  },
}));

Deduplication: content-based vs explicit MessageDeduplicationId

FIFO topics deduplicate within a 5-minute sliding window. A message is considered a duplicate if a message with the same MessageDeduplicationId (or identical SHA-256 body hash, with content-based dedup enabled) was published in the previous 5 minutes. Duplicates are silently dropped — no error is returned to the publisher.

Pitfall: If ContentBasedDeduplication is enabled on the topic and two genuinely different events happen to have identical bodies within 5 minutes (e.g., two consecutive "healthy" probes with the same JSON payload), only the first is delivered. Include a timestamp or probeRunId in the body to ensure uniqueness, or use explicit MessageDeduplicationId keyed on {endpointId}-{probeRunId}.

CDK: FIFO topic with SQS FIFO subscriber

import * as sns from "aws-cdk-lib/aws-sns";
import * as sqs from "aws-cdk-lib/aws-sqs";
import * as subscriptions from "aws-cdk-lib/aws-sns-subscriptions";
import { Duration, RemovalPolicy } from "aws-cdk-lib";

// FIFO topic — name must end in .fifo
const statusTopic = new sns.Topic(this, "McpStatusFifo", {
  topicName: "mcp-status.fifo",
  fifo: true,
  contentBasedDeduplication: false,  // use explicit MessageDeduplicationId
});

// DLQ for failed deliveries (also FIFO to preserve order in DLQ)
const statusDlq = new sqs.Queue(this, "McpStatusDlq", {
  queueName: "mcp-status-dlq.fifo",
  fifo: true,
  retentionPeriod: Duration.days(14),
});

// Main consumer queue (FIFO — required for FIFO topic subscribers)
const statusQueue = new sqs.Queue(this, "McpStatusQueue", {
  queueName: "mcp-status.fifo",
  fifo: true,
  contentBasedDeduplication: false,
  visibilityTimeout: Duration.seconds(30),
  deadLetterQueue: {
    queue: statusDlq,
    maxReceiveCount: 3,
  },
});

// Subscribe FIFO queue to FIFO topic
statusTopic.addSubscription(
  new subscriptions.SqsSubscription(statusQueue, {
    rawMessageDelivery: true,  // skip SNS envelope — consumer receives raw JSON
    filterPolicy: {
      // only route degraded/unhealthy events to this queue
      status: sns.SubscriptionFilter.stringFilter({
        allowlist: ["degraded", "unhealthy"],
      }),
    },
  })
);

Raw message delivery note: With rawMessageDelivery: true, the SQS consumer receives your original JSON body directly. Without it, the body is wrapped in an SNS envelope JSON object with fields like Type, MessageId, TopicArn, and Message (your original body as a string). Enable raw delivery when the consumer is purpose-built for this topic and you own both sides of the integration.

Throughput limits and batching

For MCP monitoring at scale (thousands of endpoints), the per-group 300 msg/s limit is not a bottleneck because each endpoint is its own group. The aggregate topic throughput scales with the number of distinct message groups in use.

Monitoring FIFO delivery with AliveMCP

FIFO topic delivery failures surface differently than standard topic failures. Because FIFO queues block on message-group head failures, a single unprocessable message can silently delay all subsequent status updates for an endpoint. AliveMCP detects this pattern indirectly: if the probe result timestamp in your status page diverges from real probe time by more than the expected processing lag, the consumer is likely blocked on a DLQ item.

CloudWatch metrics to monitor on a FIFO SNS/SQS pipeline:

# Messages waiting in main queue — should be near-zero under normal load
aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesVisible \
  --dimensions Name=QueueName,Value=mcp-status.fifo \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 60 --statistics Maximum

# DLQ depth — non-zero means a message group is blocked
aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesVisible \
  --dimensions Name=QueueName,Value=mcp-status-dlq.fifo \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 60 --statistics Maximum

Common failure modes