Tax-notice producers spike overnight while consumers process steadily by day. Where should the backlog live, and what still must run the business logic?
Select an answer to reveal the explanation.
Short Explanation
The inbox holds the mail; someone still has to open each letter. Queue stores the backlog. A Function or OKE worker does the work—config blobs are not an inbox.
Full Explanation
When tax-notice producers spike overnight and consumers drain steadily by day, the durable backlog belongs in OCI Queue. Producers put messages when volume peaks; consumers GetMessages, process, and delete at their own pace. A Function, an OKE Deployment, or any other REST/STOMP client still must run the business logic—the queue stores work, it does not execute notice generation or delivery by itself. That separation is what absorbs overnight spikes without forcing consumers to keep pace in real time.
Storing the entire backlog only in Function configuration parameters fails by concept: config is for small static settings, not a growing overnight inbox, and cold starts do not “drain” a backlog. Omitting any inbox and parking every notice solely in API Gateway route metadata fails because route metadata is not a durable message store and cannot buffer producer spikes. Using OCI Vault secret versions as the message inbox fails as well: secrets are for credentials and related material, not scalable work items; secret versioning does not grow with backlog size the way a queue channel does.
Exam caveat: Queue decouples rate; something still has to consume—do not answer “Queue alone” if the distractor implies no worker. Operational check: load a burst of test notices into a staging channel overnight schedule, confirm depth grows without producer failure, then run a Function or OKE worker and verify depth falls as messages are processed and deleted.