Which workload should not use the Message Batches API?
Why D is the answer
A pre-merge check that blocks the developer until it returns
Batch has a window of up to 24 hours and no latency guarantee, so it does not suit anything a person is blocked on. The other three can all wait.
In detail
- The Message Batches API charges 50 percent of standard prices. In exchange, batches can take up to 24 hours, although many finish sooner.
- That trade suits work where nobody is waiting. A pre-merge check blocks a developer, so a possible 24-hour wait rules it out.
- Results can come back in any order, so match them with custom_id. They stay available for 29 days after the batch is created.
- Ask one question for each workload: is anyone waiting for this result?
Use case
An illustrative scenario, not a real incident.
A team moves every review to the Batches API to save money. Nightly audits work well, but developers waiting on a pre-merge check sit for hours. The audits stay in batch, and the merge check goes back to real-time calls.
See it in different ways
flowchart TD
A{"Is someone waiting?"} -->|Yes| B["Real-time Messages API"]
A -->|No| C{"Can it wait up to 24 hours?"}
C -->|Yes| D["Message Batches API"]
C -->|No| BstateDiagram-v2 [*] --> InProgress InProgress --> Ended Ended --> Succeeded Ended --> Errored Ended --> Canceled Ended --> Expired
flowchart TD
Q{"Is someone blocked on the result?"}
Q -->|"Yes"| A0["Real-time Messages API"]
Q -->|"No, it can wait up to 24 hours"| A1["Message Batches API"]Key point: Batch saves money only on work that can wait.
Why the other options are wrong
- A. A nightly test generation run that developers review the next morning
- This suits batch: the review happens the next morning.
- B. A weekly compliance audit of every contract in the repository
- This suits batch: a weekly audit can easily wait a day.
- C. An overnight analytics report that is read at the start of the day
- This suits batch: the report is read the following day.