LearnGuides
Production Checklist
Checklist for deploying KubeMQ messaging in production.
Before working this checklist, ground yourself in the Messaging Patterns Fundamentals — especially Delivery Guarantees, since most production decisions (retries, dead-lettering, idempotency) follow from your chosen delivery semantics.
Deployment Checklist
Follow these steps before deploying KubeMQ messaging to production. Each step covers a critical area — complete all that apply to your deployment.
Connection & Security
- TLS enabled for all client connections (Connect with TLS)
- mTLS enabled for zero-trust or multi-tenant environments
- Connection timeouts configured to match network conditions
- Reconnection logic with exponential backoff implemented (Error Handling)
- Client IDs set to unique, descriptive values for traceability
- Authentication tokens rotated and not hardcoded
Observability
- OpenTelemetry configured for distributed traces and metrics (OpenTelemetry)
- Structured logging with correlation IDs linking traces to logs
- Alert thresholds set for queue depth, error rates, and latency
- Dashboard monitoring KubeMQ server health (CPU, memory, connections)
- Log retention policy configured for compliance requirements
Queues
- Dead letter queues configured for all critical queues (Dead Letter Queue)
-
maxReceiveCountset to a reasonable retry limit (default 1024 is typically too high) - Visibility timeout set to match expected processing time (Visibility Timeout)
- Message expiration (TTL) set for time-sensitive work
- Retry strategy with exponential backoff implemented
- Queue depth monitoring and alerting in place
Events Store
- Retention policy configured — time, size, or message count
- Storage utilization monitored with alerts before 90% capacity
- Durable subscription names set for consumer recovery after restart
- Replay strategy documented — consumers know which offset to start from
- Storage backend appropriate for workload (memory vs. disk)
RPC (Commands & Queries)
- Request timeouts set on all commands and queries — never use infinite timeout
- Circuit breaker in place for downstream service failures
- Query caching enabled for slow-changing data to reduce responder load
- Timeout values documented and agreed upon between caller and responder
- Load balancing strategy validated for multi-responder deployments
All Patterns
- Error handling covers all four categories: validation, connection, timeout, authorization (Error Handling)
- Graceful shutdown implemented — close connections cleanly on SIGTERM
- Idempotent message processing where applicable (at-least-once delivery)
- Message serialization format agreed upon (JSON, Protobuf, etc.)
- Channel naming convention documented and enforced
- Load testing completed under expected peak throughput
- Disaster recovery plan documented — what happens when KubeMQ restarts
Quick Reference
| Area | Key Config | Default | Recommended |
|---|---|---|---|
| Connection | TLS | Disabled | Enable in production |
| Connection | Reconnect backoff | None (SDK-dependent) | 1s initial, 30s max |
| Queues | Visibility timeout | 60s | Match your processing time |
| Queues | Max receive count | 1024 | 3–5 for most workloads |
| Queues | Message expiration | None | Set for time-sensitive messages |
| Events Store | Retention | Unlimited | Set based on storage budget |
| RPC | Request timeout | 10s | Set per operation |
| All | Client ID | Auto-generated | Set explicitly for tracing |
Next Steps
Was this page helpful?