Fictional design proposal · version 1 · for practice

Queue-backed export proposal

Move large report exports out of the web request and into a bounded worker queue. A user receives a job identifier and can check the result later.

Problem and proposed approach

Synchronous exports time out during busy periods. The proposed service records an export job, queues it, and lets a worker produce the file. The web request returns the job identifier instead of waiting for the export.

Constraints for review

• Retain generated export results for 7 days, then delete them.
• Use export_job_id as the idempotency key. Repeating a job must not produce duplicate output.
• Run at most two concurrent workers to protect the reporting database.
• Keep the existing database schema for this first release.

Alternatives considered

Increasing the request timeout keeps users waiting and does not bound database load. An unbounded worker pool risks overloading the database. A queue with two workers makes the load explicit.

Open question for the next task

How should the worker retry transient failures without producing duplicate exports? Retry timing, attempt limits, and failure reporting are still design questions.

Review exercise

Request a revision that changes result retention to 30 days. Preserve the idempotency key and concurrency limit. Review the revised fixed version, then start a new AI task to design retries using that saved source.

This is a fictional sample, not customer evidence or an approved production design.