A shop must refresh 1.2 million product records into a partner marketplace every night. The partner allows 20 requests per second and the nightly window is 4 hours. The first plan sends one record per request. Does it fit, and what does the constraint do to the design?

What is being tested

Whether you can turn an external limit into arithmetic before choosing a design. A technical constraint is a fact you cannot change by writing better code, and the right response is to see what it allows and shape the design around it.

The reasoning

Work out the budget. The window is 4 hours = 14,400 seconds. At 20 requests per second the partner will accept at most 14,400 x 20 = 288,000 requests in the window.

The first plan needs 1,200,000 requests, one per record. At 20 per second that takes 1,200,000 / 20 = 60,000 seconds, which is about 16.7 hours. It misses the window by more than four times, so it cannot work however fast the shop's own servers are. Adding more worker threads does nothing, because the limit is the partner's, and exceeding it gets requests rejected or the account throttled.

The design this forces

Check what the partner offers. If it has a bulk endpoint taking 100 records per request, the count drops to 12,000 requests, which takes 600 seconds, or 10 minutes. That fits with a wide margin.

If there is no bulk option, three moves are left, in this order:

1. Send only changes. If 3 percent of records change per day, that is 36,000 requests, or 30 minutes.
2. Spread across windows, such as refreshing each record weekly unless it changes.
3. Ask the partner for a higher limit or a file feed. This is a business conversation, not a code change.

What it costs

Sending only changes means the shop must track what changed, which adds a change log and a risk: if the log misses an update, the partner shows a stale price until the next full refresh. Keep a weekly full sync as a safety net.

When this is the wrong analysis

For 20,000 records the one-per-request plan takes 1,000 seconds, about 17 minutes, and fits comfortably. Do not add change tracking for a problem that does not exist.

Common weak answers

• "Run it in parallel." Parallelism raises your speed, not the partner's limit.
• "Buy bigger servers." Same reason.

What a strong answer adds

Keep a retry budget: with 429 responses expected, plan to use at most 70 percent of the limit so retries do not push you over.