Q: An application exposes an endpoint `/generate-report`. It takes 30 seconds to run a heavy database query and return a PDF. If three users click it simultaneously, the server CPU hits 100% and crashes. How do you redesign this architecture for scale?

The current architecture is Synchronous and deeply coupled, blocking the web server thread and exhausting resources.

• When the user hits /generate-report, the web server immediately pushes a message (JSON payload with the user ID and report parameters) onto a Message Queue (e.g., AWS SQS, RabbitMQ, Kafka).
• The web server instantly returns an HTTP 202 Accepted response with a tracking ID to the user, freeing its thread.
• An independent fleet of "Worker" instances pulls messages from the SQS queue at their own pace. If a worker can only handle 1 report at a time, it pulls 1 message. The queue absorbs the spike (buffering).

It must be redesigned to an Asynchronous / Event-Driven Pattern:

• When the worker finishes generating the PDF, it uploads it to S3, and updates a database flag or triggers a WebSocket to notify the user's frontend that the report is ready to download.