Ever wondered why some applications make you wait after clicking a button? Often the problem isn't the request itself — it's everything the application tries to do before it answers.
This video follows one example the whole way through: an online store built with Ruby on Rails. A customer places an order, and the app has to save it, send a confirmation email, notify the warehouse and run a few more tasks. Do all of that inside the web request and the customer sits there watching a spinner.
You'll see what a message queue actually is — producer, queue, consumer — and how the job moves through it: Rails creates the job, Redis stores it, a Sidekiq worker picks it up and does the slow work, while the original request returns almost immediately. The code is real: an ApplicationJob subclass and a single perform_later call.
It ends on the honest part. Queues are not magic. Jobs can fail, a message may be delivered more than once, and processing can be delayed — which is why retries, idempotency and monitoring matter. Delivery guarantees depend on the technology you choose, and Redis and Sidekiq are one option here, not a requirement for every queue. Enqueuing a job is not the same as finishing it.
CHAPTERS
0:00 — Why make users wait?
0:10 — Synchronous processing and what it costs
0:25 — Producer, queue, consumer
0:40 — The lifecycle of a job
1:00 — Active Job, Sidekiq and Redis in practice
1:25 — Benefits and trade-offs
1:45 — The takeaway
— #Astmation — #software #systems, #automation, and #AI-powered #applications. Build. Automate. Evolve. https://astmation.com/
Watch on YouTube