When you're processing 40,000+ events a month, the architecture decisions that feel optional at 100 events become mandatory.

I built a payment event orchestration system for a client that needed to route incoming webhook events — payments, refunds, failures, disputes — to different downstream workflows depending on event type. The original setup was a single Make.com scenario trying to handle everything. It worked fine at low volume, then started showing timing issues and dropped events as volume scaled.

The fix was a parent-child webhook pattern: one lightweight "router" scenario receives every event, reads the type field, and immediately fires it to the appropriate child scenario for that event type. Each child handles one thing and handles it well. Make.com + Zapier working together — Make for the high-frequency routing layer, Zapier for specific downstream actions where it had better native integrations.

What I learned: at volume, simplicity in your routing layer is more valuable than cleverness. The router should do almost nothing — classify and forward. All the logic lives downstream where it's easier to debug and modify independently.

We also added an event log table early on, which turned out to be essential. When something looks off in the financial data, you want to be able to say "here's every event we received on Thursday" without reconstructing it from logs.

Now at 40,000+ executions/month with a clear audit trail. The complexity went from one big scenario to several small, focused ones — and that's the better trade.