A nightly job must extract fields from 100,000 records as cheaply as possible, and it can wait. What fits?
Why D is the answer
The Message Batches API
Batch work costs 50 percent of standard prices and can take up to 24 hours. Use custom_id to match results, which can return in any order.
In detail
- The job can wait, so it fits the Message Batches API.
- Batch work costs 50 percent of standard prices and can take up to 24 hours.
- Results can return in any order, so use custom_id to match them to records.
- Give each request a custom_id that maps straight back to your record.
Use case
An illustrative scenario, not a real incident.
A retailer extracts fields from 100,000 product records each night. Results are needed by morning, so the job goes through the Message Batches API at half the standard price, with each record's ID as its custom_id.
See it in different ways
stateDiagram-v2 [*] --> Processing Processing --> Ended Ended --> Succeeded: use the result Ended --> Failed: errored or expired Failed --> Processing: resubmit by custom_id Succeeded --> [*]
flowchart LR S0["Build requests with custom_id"] --> S1["Submit the batch"] --> S2["Wait up to 24 hours"] --> S3["Match results by custom_id"]
Key point: If it can wait, batch it.
Why the other options are wrong
- A. Several API keys sharing the load, so that the rate limit is never reached
- Rate limits are not meant to be avoided with extra keys, and this saves no money.
- B. One real-time request per record, sent with streaming turned on
- Real-time requests pay full price for speed the job does not need.
- C. A single huge request that holds all of the records at the same time
- One huge request would not fit, and one failure would affect everything.