The Batch API: the discount almost nobody uses

A discount that survives on paper and dies in the backlog

This is a short piece about a specific, narrow failure of prioritisation — not about the batch API's mechanics, which live elsewhere on this site, but about why a genuinely good, well-understood optimisation keeps losing to whatever's loudest that week.

The Message Batches API offers a real, substantial discount, the mechanics of qualifying for it are well understood, and a large share of eligible workloads never move over anyway. That gap between "clearly worth it" and "actually done" isn't a technical problem — the technical case for batching an obviously asynchronous workload is rarely in dispute once someone looks. It's a prioritisation problem, and prioritisation problems are the ones that survive indefinitely, because nothing about them looks urgent.

Why "eventually" is where good batch candidates go to die

A workload correctly identified as batchable, and left synchronous "for now," tends to stay synchronous for a very long time — not because anyone decided against migrating it, but because nobody decided for it either, with enough force to put it on a schedule. The workload keeps working. The cost is merely suboptimal, not broken, and merely-suboptimal loses every prioritisation conversation against a feature that's actively on fire. A clear batch candidate sitting in a backlog isn't blocked by disagreement; it's blocked by the absence of anything forcing a decision one way or the other.

The reframe that actually gets it scheduled

The fix isn't a better argument for why batching matters in the abstract — everyone already agrees it matters in the abstract. The fix is converting an abstract efficiency gain into a specific number attached to a specific, already-identified workload: not "we should batch more of our infrastructure" but "this workload, migrated, saves this much every month at current volume." A vague efficiency improvement competes for engineering time against a concrete feature request and loses almost every time; a dollar figure attached to a named, ready-to-migrate workload competes on much more even terms, and is usually the actual difference between a migration that happens and one that sits in a backlog indefinitely.

Why this specific discount is unusually well-suited to that reframe

Not every cost optimisation converts cleanly into a clean, defensible number — plenty of efficiency work has a real but fuzzy payoff that's hard to pin down precisely. Batch migration isn't like that: given a workload's actual volume and the standard-versus-batch price difference, the monthly saving is a concrete, computable figure, not an estimate hedged with qualifiers. That's a genuine advantage this specific optimisation has over a lot of the other efficiency work competing for the same engineering time, and it's worth using deliberately rather than defaulting to the vaguer pitch most efficiency proposals get stuck making.

What actually kills the momentum after the number is in hand

Even with a strong number attached, a migration that gets scoped as "convert the whole pipeline" tends to stall, because that's a large, discrete chunk of work competing against smaller, faster-to-ship priorities. A migration scoped as "convert the single highest-volume, most clearly asynchronous piece first" is small enough to actually fit into a normal sprint, produces a working reference implementation, and — critically — produces its own fresh, concrete savings number once it ships, which is exactly the kind of evidence that makes scheduling the next piece an easier conversation than the first one was.

A pattern worth recognising beyond this one API

None of this is really specific to batch pricing — it's a general shape that shows up anywhere an optimisation is real, well-understood, and nobody's job depends on shipping it. The lesson worth carrying elsewhere is the reframe itself: an abstract "we should do this" competes poorly for attention regardless of how true it is, and a concrete number attached to a named, ready piece of work competes on completely different terms. If you're sitting on a different optimisation that's been "worth doing eventually" for longer than it should have been, the same fix likely applies — find the number, attach it to the smallest shippable piece, and stop arguing the general case in meetings where nobody's actually empowered to schedule it.

See when batch processing is worth the wait for the technical decision framework — which workloads actually qualify, and the deadline math worth getting right before committing — and the batch vs realtime calculator for the number this whole argument depends on having in hand.