anti-patterns: #16 batch write-limit, #17 fester delay für bulk

ANTI-PATTERNS.md

@@ -229,3 +229,35 @@ await api.post(`/rest/items/${itemId}/variations/${varId}/variation_properties`,
 **Fix:** Bulk-Operationen immer sequenziell (eins nach dem anderen). Delay ≥ 1.500ms wenn andere Services parallel laufen. **Siehe DOJO.md #2**
 
 ---
+
+## 16. `/rest/batch` als Write-Limit-Umgehung erwarten
+
+```javascript
+// FALSCH: "20 Writes in einem Request = nur 1 Write fürs Budget"
+const payloads = items.slice(0, 20).map(i => ({ resource: '...', method: 'POST', body: {...} }));
+await fetch('/rest/batch', { body: JSON.stringify({ payloads }) });
+// → Zählt intern als 20 einzelne Writes!
+```
+
+**Problem:** `/rest/batch` reduziert HTTP-Roundtrips, aber das Write-Budget von Plenty zählt jede Operation einzeln. 20 Writes pro Batch = 20 Writes fürs Rate Limit. Kein Vorteil beim "long period write limit".
+
+**Fix:** Batch nur für HTTP-Overhead-Reduktion nutzen, nicht als Rate-Limit-Umgehung. Für Writes AIMD-basiertes Rate Limiting verwenden. **Siehe DOJO.md #29, #30**
+
+---
+
+## 17. Fester Delay für lang laufende Bulk-Operationen
+
+```javascript
+// FALSCH: Fester Delay für tausende Requests
+const DELAY = 1000; // Tagsüber zu schnell, nachts zu langsam
+for (const item of items) {
+  await sleep(DELAY);
+  await api.post(...);
+}
+```
+
+**Problem:** Tagsüber konkurrieren andere Services um dasselbe Rate-Limit-Budget → 429er. Nachts ist die API frei → unnötig langsam. Fester Delay kann beides nicht optimal bedienen.
+
+**Fix:** AIMD Rate Limiting: bei Erfolg schneller werden, bei 429 verdoppeln. Konvergiert automatisch zum Optimum. **Siehe DOJO.md #30**
+
+---