Azure Service Bus für EC-Bestellungen mit Claude Code entwerfen

Wo EC-Bestellflüsse brechen

Order accepted, inventory reserve, shipping request, mail send und retry gehören nicht in eine Queue.
Ein Topic passt, wenn ein Bestellereignis an Bestand, Versand, Mail und Analyse verzweigt.
MessageId muss stabil aus Bestellung, Position und Aktion entstehen.
Die Dead-letter Queue ist ein Prüftisch, kein blinder Resend-Knopf.
Claude Code schreibt Tabellen; Zahlung, Erstattung, personenbezogene Daten und Freigabe bleiben beim Menschen.

The Microsoft documentation for Service Bus overview, queues, topics, and subscriptions, dead-letter queues, duplicate detection, message transfers, and pricing tiers is the source base. The internal Azure memo pattern is also related to the Azure OpenAI privacy memo.

Was Claude Code vorbereitet und was Menschen prüfen

In einem EC-Shop liegen Bestellansicht, Inventar-CSV, Versandauftrag, Mail-Log und Retry-Notiz oft getrennt. Wenn jemand das ganze Bestellereignis erneut sendet, obwohl nur die Mail fehlgeschlagen ist, kann Bestand doppelt reserviert werden. Dieser Artikel macht aus Azure Service Bus eine einfache Tabelle. Claude Code should read column names, event names, retry samples, and DLQ reason text. It should not receive card data, full address text, refund judgment, or credentials. The output should be a table with event name, input columns, queue or topic, subscription, MessageId, DLQ owner, retry condition, and human review.

Humans keep payment state, refund permission, privacy policy, stock finalization, warehouse contract, apology text, and release approval. This split matters because a technically valid retry can still be a business mistake. The table makes the stop point visible before production.

Drei Use Cases

Use case 1

Eine akzeptierte Bestellung startet mehrere Arbeiten. Eingabe: CSV, order id, line item, SKU, Menge, Zahlungsstatus, Mail-Flag. Ausgabe: topic:orders mit Subscriptions für Bestand, Versand, Mail, Analyse. Menschliche Prüfung: unbezahlte Bestellung, Vorbestellung, Bundle, Geschenk, manuelle Bestandskorrektur, Mailtext.

Use case 2

Bestandsreservierung braucht einen stabilen fachlichen Schlüssel. Eingabe: order id, line item, SKU, Menge, reserve-Aktion, Sendelog. Ausgabe: MessageId-Tabelle wie order id plus line item plus reserve. Prüfung: Mengenänderung, Storno, erneute Bestellung, Bundle-Split, Rückbuchung.

Use case 3

Die DLQ muss für Operations lesbar sein. Eingabe: reason, description, order id, SKU, Fehlerzahl, letzte Zeit, Memo. Ausgabe: auto retry, korrigieren und senden, Bestellung halten, Erstattung prüfen, Entwicklung untersuchen. Prüfung: Kunde, Lager, Bestand, Erstattung, Rechte.

Prompt zum Kopieren

You are preparing an Azure Service Bus design memo for an EC store.
Inputs: order CSV columns, inventory CSV columns, event names, retry logs, DLQ reason samples, and planned Azure tier.
Output:
1. Event table with eventName, input columns, queue or topic, subscription, MessageId, and DLQ owner.
2. Human review table for payment, refund, personal data, stock finalization, customer notice, and resend approval.
3. MessageId naming rules based on order id, line item id, and action.
4. DLQ classification: auto retry, fix then retry, hold order, refund review, engineering investigation.
5. One first action that can be done in 30 minutes.
Rules: do not put card data or full address text in messages. Do not blindly resend every DLQ message.

Prüfcode

const events = [
  { type: "order.accepted", orderId: "ORD-1001", lineItemId: "1", sku: "TSHIRT-M", quantity: 2, action: "accept" },
  { type: "inventory.reserve", orderId: "ORD-1001", lineItemId: "1", sku: "TSHIRT-M", quantity: 2, action: "reserve" },
  { type: "inventory.reserve", orderId: "ORD-1001", lineItemId: "1", sku: "TSHIRT-M", quantity: 2, action: "reserve" },
  { type: "mail.send", orderId: "ORD-1001", lineItemId: "", sku: "", quantity: 0, action: "confirmation" },
  { type: "inventory.reserve", orderId: "", lineItemId: "2", sku: "MUG-BLUE", quantity: 1, action: "reserve" },
  { type: "shipping.requested", orderId: "ORD-1002", lineItemId: "1", sku: "BAG-BK", quantity: 1, action: "ship" }
];

function routeEvent(event) {
  if (event.type === "order.accepted") {
    return {
      entity: "topic:orders",
      messageId: event.orderId + ":accepted",
      reason: "fan out to inventory, shipping, mail, and analytics subscriptions"
    };
  }
  if (event.type === "inventory.reserve") {
    return {
      entity: "queue:inventory-reserve",
      messageId: event.orderId + ":" + event.lineItemId + ":reserve",
      reason: "one stock reservation worker should own this line item"
    };
  }
  if (event.type === "mail.send") {
    return {
      entity: "queue:mail-send",
      messageId: event.orderId + ":" + event.action,
      reason: "mail can retry without touching stock"
    };
  }
  return {
    entity: "needs-design-review",
    messageId: event.orderId + ":" + event.type,
    reason: "route is not documented yet"
  };
}

const seen = new Set();
const findings = [];

for (const event of events) {
  const route = routeEvent(event);
  if (!event.orderId) {
    findings.push({
      type: "missing-order-id",
      eventType: event.type,
      fix: "do not send this message until the order id is present"
    });
  }
  if (seen.has(route.messageId)) {
    findings.push({
      type: "duplicate-message-id",
      eventType: event.type,
      messageId: route.messageId,
      fix: "keep the same MessageId for sender retry, but make the handler idempotent"
    });
  }
  if (route.entity === "needs-design-review") {
    findings.push({
      type: "unknown-route",
      eventType: event.type,
      fix: "decide queue, topic subscription, DLQ owner, and retry rule before release"
    });
  }
  seen.add(route.messageId);
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Pitfall: häufige Fehler

The first cause is one queue for every action. The fix is to use a topic for order accepted and separate queues or subscriptions for inventory, shipping, and mail. This prevents a mail retry from touching stock again.

The second cause is random MessageId generation. The fix is to generate the id from order id, line item id, and action before sending. Duplicate detection can only help inside the configured window when the id stays stable.

The third cause is blind DLQ resend. The fix is to classify each reason into auto retry, fix then retry, hold order, refund review, or engineering investigation. Messages that affect customers or refunds need human review.

The fourth cause is ignoring tier differences. The fix is to check whether topics, transactions, de-duplication, or sessions are required before choosing Basic, Standard, or Premium.

FAQ

Q. Should every EC event be a topic? A. No. Topic is useful when one event fans out. A queue is clearer when one worker owns one task such as inventory reservation or mail send.

Q. Does duplicate detection remove all double stock moves? A. No. It helps when MessageId is stable. The handler should still check whether the line item was already processed.

Q. Who should read DLQ? A. Operations and developers. EC failures can involve customer notice, refund, stock gap, and warehouse contact.

Q. What should message body contain? A. Prefer order id, line item id, SKU, quantity, and reference id. Review personal data and logging policy before adding sensitive text.

Pfad zur Beratung

Für EC-Teams zählt weniger falscher Bestand, weniger Versandverzug und weniger Support. Bringen Sie CSV-Spalten, drei Fehler und den aktuellen Retry-Ablauf in die Beratung. Use Claude Code training and consultation when the team needs help turning order CSV, inventory CSV, retry logs, and release approval into a workflow.

Was ich geprüft habe

Geprüft wurden Microsoft Learn zu Service Bus, Queues/Topics/Subscriptions, DLQ, Duplicate Detection, Transfers und Tiers. Der lokale Code meldet fehlende order id, doppelte MessageId und unbekannte Route. Der erste Schritt ist eine Tabelle für Bestellung, Bestand, Mail und Retry.