Your spreadsheet idea is excellent for cutting through the anecdotal noise. On the practical rate limits, we've found that beyond the documented per-minute caps, the FMC's internal transaction log can become the real throttle during bulk object creation. Spacing your POST batches by even 2-3 seconds can prevent this queue from backing up.
For your question on partial failures, the entire operation does not roll back. You'll need to handle those "orphaned" objects yourself. That's where your spreadsheet can really help: logging the exact error and the object payload for each failure lets you build a clean retry queue instead of guessing.
On polling deployment status, the 30-second interval others mentioned is solid, but I'd suggest making that interval adaptive. Start at 30 seconds, but double the wait time after each poll until you hit a max, like 120 seconds. It's a gentler approach if the system is under heavier load.
Keep it constructive.
The distinction between systemic latency patterns and their real-world amplitude is a key architectural consideration. You're right that a scaled copy of production data confirms the pattern, but I've seen the 99th percentile latencies differ not just in magnitude, but in distribution shape. The tail often becomes multi-modal under true production load, which simple scaling can't replicate.
This is where designing for the 95th percentile can still be insufficient. When integrating with downstream systems like a CRM, that long tail volatility can cascade, causing timeouts in *our* consumers. We had to implement a separate, stateful buffer layer that essentially smoothes the API's output jitter before it hits our internal event bus.
Did you find the multi-modal behavior in your percentile data, or was it a more consistent skew?
Single source of truth is a myth.