The CRM Sync Engine I Had to Reverse‑Engineer: Two‑Step Fetches, 50‑Field Limits, and a Mapper That Refuses to Drift

I found the bug the way you always find the worst ones: not in a unit test, not in staging, but in a "why is this field blank again?" message after a real sync. The Zoho CRM API call looked correct. The request even included a fields parameter. And yet the response kept arriving with a drifting set of columns—sometimes missing the ones I explicitly asked for. That was the moment I stopped treating the API docs as a contract and started treating them as a suggestion. The CRM is a noisy sensor. The sync engine is the signal conditioner. Once you see it that way, the architecture writes itself. This is Part 7 of my series "How to Architect an Enterprise AI System (And Why the Engineer Still Matters)" . Part 6 was about building claim/unclaim workers with SKIP LOCKED . The key insight: treat the CRM as an adversarial input stream The non-obvious part isn't "sync records from a CRM." The non-obvious part is accepting that the CRM will: ignore parameters that look mandatory, enforce limits t