AI strengths and weaknesses for queue architecture

Prompt templates

Prompt 1: Choosing queue technology

I need to choose a message queue for the following scenario:
- 500 messages/second at peak
- Messages are JSON, average 2 KB each
- Need at-least-once delivery
- Team of 4 developers, no dedicated DevOps
- Running on AWS
- Budget: $200/month for messaging infrastructure
- Consumers process each message in ~200ms

Compare RabbitMQ, Kafka, and SQS for this use case.
Rank them by: operational simplicity, cost, and fit for requirements.

What AI typically returns (and it is mostly useful):

const comparison = {
  sqs: {
    operationalSimplicity: "10/10 - fully managed, zero ops",
    monthlyCost: "CODE_BLOCK5-30 (500 msg/s * 86400s * 30 = 1.3B requests, ~$0.40/M)",
    fit: "Excellent for this scale. At-least-once built in.",
    downside: "No strict ordering without FIFO (which has lower throughput)"
  },
  rabbitmq: {
    operationalSimplicity: "5/10 - need to manage cluster, upgrades, monitoring",
    monthlyCost: "$50-100 (AmazonMQ) or $20/month self-hosted EC2",
    fit: "Good. More features than needed at this scale.",
    downside: "Operational burden for a 4-person team without DevOps"
  },
  kafka: {
    operationalSimplicity: "2/10 - complex to operate, tune, and monitor",
    monthlyCost: "$200-400 (MSK) or significant self-hosted effort",
    fit: "Overkill. Designed for 100K+ msg/s, not 500.",
    downside: "Over budget, over-engineered, operational nightmare for small team"
  },
  recommendation: "SQS. Zero ops, lowest cost, fits all requirements."
};

This is a case where AI gives a reasonable answer. But notice the default: if you did not constrain the prompt with team size and budget, AI would likely recommend Kafka "for future scalability." Always anchor AI with your real constraints.

Prompt 2: Designing queue topology

Design a message queue topology for an e-commerce order pipeline:

1. User places order (synchronous API response)
2. Payment processing (may fail, needs retry)
3. Inventory reservation (must happen after payment)
4. Email confirmation (non-critical, can be delayed)
5. Analytics tracking (fire and forget)

For each step, specify:
- Queue name
- Delivery guarantee needed
- Retry strategy
- DLQ policy
- Consumer count recommendation

This prompt works well because it forces AI to think about each step independently rather than applying one-size-fits-all settings. The AI will typically produce a sensible topology, but you should verify the retry counts and delays against your SLAWhat is sla?A formal commitment defining the minimum uptime or performance level a service promises to deliver, usually expressed as a percentage like 99.9%. Ask AI for more requirements.

Prompt 3: Capacity planning

Help me calculate queue capacity requirements:

- 10,000 orders per day
- Peak traffic is 3x average (lunch and evening rushes)
- Each order generates 4 messages (payment, inventory, email, analytics)
- Average message size: 1.5 KB
- Payment processing takes 2 seconds per message
- Other consumers process in under 200ms
- We want to handle a 30-minute traffic spike without falling behind

Calculate:
1. Average and peak messages per second
2. Required consumer count per queue
3. Queue storage needed during peak backlog
4. Monthly cost estimate on AWS SQS

AI is genuinely good at this math. It will break down the numbers correctly:

const capacityPlan = {
  averageMPS: 10000 * 4 / 86400,          // ~0.46 msg/s
  peakMPS: 0.46 * 3,                       // ~1.39 msg/s
  paymentConsumers: Math.ceil(1.39 * 2),    // 3 (peak RPS * processing time)
  otherConsumers: 1,                        // 1 each (fast processing)
  peakBacklog: 1.39 * 1800 * 1.5,          // ~3,750 KB = 3.7 MB
  monthlySQSCost: "< $5"                    // Very low volume
};

What to verify: common AI mistakes

1. AI defaults to Kafka for everything.
Ask AI "what queue should I use?" and 70% of the time it says Kafka. Kafka is designed for massive throughputWhat is throughput?The number of requests or operations a system can handle per unit of time, like requests per second. Ask AI for more (hundreds of thousands of messages per second) and event streaming. If you are processing 100 orders per minute, Kafka is a forklift for a job that needs a wheelbarrow. Push back: "My peak throughput is X msg/s. Do I actually need Kafka?"

2. AI underestimates operational complexity.
AI will say "deploy a 3-node Kafka cluster" as if it is as simple as npm install. In reality, operating Kafka means managing ZooKeeper (or KRaft), tuning partition counts, monitoring consumer lag, handling broker failures, managing schemaWhat is schema?A formal definition of the structure your data must follow - which fields exist, what types they have, and which are required. Ask AI for more registryWhat is registry?A server that stores and distributes packages or container images - npm registry for JavaScript packages, Docker Hub for container images. Ask AI for more, and dealing with disk space. For a small team, this operational burden can consume 20-30% of an engineer's time. Always ask: "What is the operational cost of running this?"

3. AI ignores cost at small scale.
AI might suggest Amazon MSK (managed Kafka) at $200/month when SQS would cost $5/month for your workload. It optimizes for "architectural correctness" rather than practical economics. Always ask: "What would this cost for my specific message volume?"

4. AI generates overly complex retry strategies.
AI loves to design five-layer retry topologies with different backoff strategies per queue. For most systems, a simple exponential backoffWhat is exponential backoff?A retry strategy where each attempt waits twice as long as the previous one, giving an overloaded server progressively more time to recover. Ask AI for more with 3-5 retries and a DLQ is sufficient. Complexity in retry logic is itself a source of bugs.

5. AI forgets about message ordering implications.
When AI suggests partitioning strategies, it often picks partition keys that do not match your ordering requirements. If you need all messages for the same order to be processed in sequence, you need to partition by order ID. AI might default to random partitioning for "better load balancing" without considering the consequences.

The hybrid workflow

Step 1: AI drafts the architecture.
Give AI your requirements (throughputWhat is throughput?The number of requests or operations a system can handle per unit of time, like requests per second. Ask AI for more, team size, budget, SLAWhat is sla?A formal commitment defining the minimum uptime or performance level a service promises to deliver, usually expressed as a percentage like 99.9%. Ask AI for more) and ask it to propose a queue topology with technology choice. This takes 2 minutes instead of 2 hours of research.

Step 2: You challenge the technology choice.
Ask yourself:

• Can my team operate this without a dedicated DevOps engineer?
• Does the managed version fit my budget?
• Am I paying for 100x the capacity I need?
• Is there a simpler option that meets my actual requirements?

Step 3: AI refines based on your constraints.
Feed your corrections back: "We decided on SQS instead of Kafka. Redesign the topology for SQS, including FIFO queues where we need ordering."

Step 4: You validate against real-world operations.
Check the AI's design against production realities:

// Validation checklist for AI-generated queue architecture
const validationChecklist = {
  technology: "Can my team operate this? What's the managed cost?",
  retryStrategy: "Are retry counts and delays realistic for my SLAs?",
  dlqPolicy: "Who monitors the DLQ? How fast must we respond?",
  consumerCounts: "Did AI account for peak traffic, not just average?",
  messageSize: "Did AI use realistic message sizes, not minimums?",
  orderingNeeds: "Does the partition strategy preserve required ordering?",
  costEstimate: "Did AI include data transfer, storage, and API call costs?",
  failureScenarios: "What happens if the queue itself goes down?"
};

The most common pattern: AI suggests a technically elegant architecture that your team cannot afford to build or operate. Your job is to simplify it down to what actually works for your situation. Start with the simplest queue technology that meets your requirements, and migrate to something more powerful only when you hit real limitations, not theoretical ones.