What are some real-world applications of Queues? (Task scheduling, Printer spooling)

Imagine you're building a feature for a photo-sharing app where users can upload multiple high-res images at once. We don't want to freeze the UI while resizing them. How would you use an in-memory queue to handle these resizing tasks in the background, and what happens to those tasks if the user closes the app mid-way?

Let's say we are writing a simple print server that receives documents from multiple computers. If five people hit 'print' at the exact same millisecond, how does a queue help us ensure fairness, and how would you handle a situation where one print job is massive and blocks everyone else?

We have a customer notification service that sends out emails. Currently, when a user triggers an event, we write a task to an in-memory queue. However, during peak traffic, our server crashed and we lost thousands of pending emails. How would you redesign this queueing mechanism to prevent data loss, and what tradeoffs do we make by moving away from an in-memory queue?

You're debugging a background worker pool that processes payment transactions from a queue. We're seeing a bug where some transactions are processed twice because a worker takes too long and the queue system thinks it failed, so it re-delivers the message. How would you investigate and resolve this 'at-least-once' delivery issue?

We are designing a distributed web crawler that needs to process millions of URLs daily. We want to use a queue to manage the URLs to visit, but we must respect robots.txt rate limits (e.g., don't hit the same domain more than once every 5 seconds). How would you design the queueing and scheduling architecture to enforce this domain-level rate limiting at scale?

Our e-commerce platform uses a message queue to handle order processing. During flash sales, the queue builds up a massive backlog, causing a 15-minute delay for order confirmations. How would you design a backpressure and scaling strategy for our consumer pool to handle these sudden spikes without crashing downstream databases?

Our company is migrating from a legacy, database-backed queueing system to a dedicated event-streaming platform like Kafka to handle 100x our current throughput. How do you plan this migration to ensure zero downtime, maintain message ordering for critical financial transactions, and handle the organizational shift for product teams who are used to traditional transactional queues?

We need to build a centralized, multi-tenant task execution platform used by 50 different internal engineering teams. Some teams run fast, low-priority tasks, while others run slow, mission-critical ones. How would you architect the queueing infrastructure to guarantee fair resource allocation, prevent noisy-neighbor issues, and enforce strict SLAs across these teams?