Make.com at scale: patterns to reduce operational cost and improve latency

Make.com is an exceptional tool when you are starting out, but it becomes a significant cost once you cross a certain threshold. Among Italian mid-market ecommerce companies running orders, inventory, customer service and logistics through Make, it is normal to reach sixty to eighty active scenarios within a couple of years, with monthly consumption above a million operations. At that point the subscription plan becomes visible on the P&L, and — more importantly — the latency of critical scenarios such as order confirmation starts to degrade.

This article describes the approach I apply during a Make audit on an account at scale. These are not theoretical best practices: they are patterns I used recently in an engagement on an ecommerce account with sixty-three active scenarios in the B2B distribution space, with the goal of cutting operations consumption without losing reliability. The result was a drop from about 2.5 million to 1.5 million operations per month — roughly 40% less — and end-to-end latency for the “Order Confirmed” scenario brought stably under two seconds.

Where to start: the consumption map

The first mistake in a Make audit is to look at scenarios one by one. People tend to optimize the scenarios they know best, which are often not the ones consuming the most. The first step I always take is to generate a consumption map, ops per scenario, sorted descending, over the last four weeks.

In almost every audit I have seen the same distribution: 70 to 80% of operations are concentrated in five to eight scenarios. They are almost always scenarios triggered at high frequency (webhook, minute-level polling, pg_cron) with external lookups inside the loop. The rest of the scenarios, while numerous, count for little in cost terms. Focusing refactoring effort only on the top consumers delivers the highest return.

Pattern 1: Data Store instead of Sheet lookup

The most frequent pattern I find in poorly scaled accounts is the use of Google Sheets as a lookup database. Typically: the scenario receives an order webhook, runs a “Search Rows” on a Sheet to fetch product metadata (category, supplier, shipping rule), and proceeds. It is a solution that works perfectly fine as long as the Sheet has a few hundred rows and the scenario runs a few times a day. At real volumes — ten thousand rows in the Sheet, two thousand triggers per day — it becomes the single most expensive point in the setup.

The refactor is to replace the Sheet lookup with a native Make Data Store. The Data Store is designed exactly for this: lookup by key, marginal ops cost, latency in milliseconds instead of seconds. In the audit cited, replacing seven recurring Sheet lookups with Data Store cut roughly 400,000 ops per month and reduced average latency of the affected triggers by 60 to 70%.

There is an important trade-off: the Sheet is human-readable, the Data Store is not. To keep the operational benefit of the Sheet — the fact that the operations team can update it manually — the solution I adopted is a bidirectional sync scenario Sheet → Data Store every fifteen minutes. The Sheet remains the editable source, the Data Store is the fast copy used at runtime.

Pattern 2: sequential processing on high-volume webhooks

On a webhook receiving a hundred events per minute during promotional peaks, Make’s default behavior is to execute bundles in parallel. It is efficient, but on scenarios that write to shared resources (a counter, an order status, a stock row) it generates race conditions: two concurrent executions read the same value, modify it, and the last one overwrites the first. The bug is intermittent, hard to reproduce, and almost always discovered after an incident with a customer.

The pattern I apply is to force sequential processing of bundles on the critical webhook, accepting the throughput cost in exchange for consistency. In Make you do this by configuring the webhook to process one bundle at a time and sizing a small upstream buffer. For webhooks where sequentiality is not negotiable (e.g. order status events), this pattern eliminated an entire class of bug that the team had previously been handling with manual customer service corrections.

Pattern 3: custom monitoring beyond Run History

Make’s Run History is useful for ad-hoc debugging but it is not a monitoring system. It has no alerting, no trend dashboards, it does not easily distinguish between transient failures and structural degradations. For any account running above a million operations per month, it is worth building a custom monitoring layer.

The minimum pattern I implement is a meta-scenario that, at regular intervals, queries the Make API to retrieve failure rate, queue depth and average execution time of critical scenarios. The data lands in a Sheet or Data Store, and on predefined thresholds an alert is fired to Slack or email. It sounds redundant, but it is what allows you to notice degradation a day before the customer calls.

Pattern 4: latency budget for critical scenarios

For a customer-facing scenario like “Order Confirmed” — the one triggered by the Shopify webhook that must produce the confirmation email, the WhatsApp message, the CRM record and the operational tag — the latency budget must be explicit. The question to ask is not “what is the average time”, but “what is the 95th percentile time on a peak day”. User experience breaks on peaks, not on averages.

To bring a scenario of this type stably under two seconds, there are four levers. Eliminate every HTTP call not strictly necessary in the synchronous path, moving it to an asynchronous child scenario. Replace Sheet lookups with Data Store as described above. Eliminate the unnecessary “router” modules the team accumulated during development. Group writes to the same resource into a single bulk module where the API supports it.

The five-step audit framework

The approach I apply is structured. Week one: consumption map, identification of top consumers, latency baseline. Week two: refactoring recurring lookups to Data Store. Week three: introduction of the monitoring layer and sequential webhooks where needed. Week four: latency optimization of critical scenarios and cleanup of obsolete scenarios. Week five is dedicated to documentation and training of the internal team, because an audit that does not leave maintenance capacity in-house is an audit you pay for twice within a year.

Take-aways

Three key points for anyone evaluating an optimization intervention on a scaled Make account. First: cost does not cut uniformly, it cuts on top consumers. Identifying them before touching code is half the work. Second: Data Store vs Sheet is the single architectural decision that produces the biggest ops saving on ecommerce accounts; it is almost always worth the refactor. Third: latency is a percentile problem, not an average problem. If you are not measuring the p95 of your critical scenarios, you are optimizing blind. A well-executed audit, on an account above a million operations per month, typically returns payback in under a quarter on direct Make plan savings alone, without counting the hours freed up for the operations team by proactive monitoring.