Optimize Pub/Sub Subscriber Performance

This skill designs, implements, and optimizes pub/sub subscribers across Google Cloud Pub/Sub, Apache Kafka, RabbitMQ, Redis Pub/Sub, AWS SNS/SQS, and Azure Service Bus. It's built around core message-processing patterns - at-least-once delivery with idempotent processing, exactly-once semantics via deduplication, ordered processing for order-sensitive workloads, parallel processing balanced against resource limits, and dead letter queues for poison messages - plus subscriber-reliability practices: explicit acknowledgment, exponential-backoff retries, per-message timeouts, circuit breakers for downstream dependencies, and monitoring of message lag and processing rates.

It provides two full implementation patterns: a Google Cloud Pub/Sub subscriber using a thread-pool executor with flow control (a capped number of unacknowledged messages) and explicit ack/nack on success or failure, and a Kafka consumer with exponential-backoff retry logic, manual offset commits (only after successful processing), and dead-letter handling for messages that exhaust all retries. Configuration guidance covers flow-control and performance tuning for both platforms - GCP subscriber settings (max unacknowledged messages, max bytes, max latency, worker count, ack deadline) and Kafka consumer settings (max poll records, fetch size and wait time, session timeout, heartbeat interval).

It also covers health monitoring with a sliding-window metrics tracker (messages per second, error rate, average processing time), batch processing with combined size- and time-based flush triggers, and horizontal scaling guidance (monitoring CPU/memory/network, scaling on message lag, using consumer groups for load distribution, graceful shutdown with message drain, and autoscaling on queue depth).

def handle_dead_letter(self, message):
    """Handle messages that failed all retry attempts"""
    self.failed_messages.append({
        'topic': message.topic,
        'partition': message.partition,
        'offset': message.offset,
        'value': message.value,
        'timestamp': time.time()
    })

Use this skill when building or hardening a message subscriber for an event-driven architecture - choosing a processing pattern (idempotent, deduplicated, ordered, or parallel), tuning flow control and consumer settings, adding retry and dead-letter handling, or preparing a production deployment checklist for a queue or streaming consumer.

It is not a fit for designing the publisher side or the broader event schema - the guidance is scoped to subscriber-side reliability, processing, and scaling, assuming messages are already being published.

Inputs are your target messaging platform (Pub/Sub, Kafka, RabbitMQ, Redis, SNS/SQS, or Service Bus), expected message volume, and ordering/deduplication requirements. Outputs are a working subscriber implementation, tuned configuration, a metrics tracker, and the production checklist items this skill also covers: structured logging with correlation IDs for tracing a message through the pipeline, resource limits and requests set explicitly in containerized environments, configured message-retention policies, proper authentication and authorization on the subscriber connection, and garbage-collection tuning for long-running consumer processes.

The platform coverage spans Google Cloud Pub/Sub, Apache Kafka, RabbitMQ, Redis Pub/Sub, AWS SNS/SQS, and Azure Service Bus; scaling guidance additionally recommends consumer groups for automatic load distribution across instances and autoscaling driven by queue depth rather than fixed instance counts.

Backend and platform engineers building event-driven consumers who need concrete, production-ready subscriber patterns - reliable acknowledgment, retry and dead-letter handling, batching, and a deployment checklist covering correlation-ID logging, lag alerting, and resource limits - rather than assembling subscriber reliability logic from scratch per platform.