All posts

Why your API feels slow, drawn on a napkin

Backend · 3 min read ·

A client once told me: "the signup button takes 4 seconds, fix the database." The database was fine. The endpoint was sending a welcome email before answering the user. Here is the whole problem in one sketch:

Browser Your API Email service 3 whole seconds the user stares at a spinner this whole time
Everything happens in one line. The slowest step decides the response time.

The fix: answer first, work later

The user does not need the email to exist before they see "account created". They need the promise that it will exist. So we split the timeline: respond right away, and push the slow work onto a queue that a worker chews through in the background.

Browser Your API "done!" in 50 ms jobs pile up here, nobody is waiting on them Queue Worker email goes out seconds later
Two timelines instead of one. The user only ever sees the short one.

In Laravel this is three lines

Push the work to a queued job and return immediately:

SendWelcomeEmail::dispatch($user); inside the controller, php artisan queue:work on the server, and QUEUE_CONNECTION=redis in the environment. That is the entire pattern.

Rule of thumb I use on every project: if the user does not need the result of a task to continue, that task does not belong in the request. Emails, PDFs, image resizing, webhooks, analytics: queue all of it.

At Tamkeen I spent a good part of six months moving work out of requests and into queues. Same servers, same database, and endpoints that used to take seconds started answering in double-digit milliseconds.

Notes from readers

  1. No notes yet. The first one is the bravest.
Building something like this? I can help. Contact