The one thing WordPress's synchronous mail can't do

The one thing WordPress's synchronous mail can't do

Here's a failure mode every PHP CMS quietly shares: a contact form, or an order confirmation,

sends an email on the request. When the mail gateway is fast, nobody notices. When it's slow,

the request waits — and a handful of concurrent submissions can take the whole site down with it.

We measured it in LOOK, honestly, because we wanted to know where our own model was fragile. With

two worker threads and a slow (blackhole) SMTP server, **two concurrent form submits blocked both

workers, and the homepage timed out for everyone** — a 3rd-connection probe showed 2 of 3 requests

hanging. This is not a connection-model quirk; a blocking outgoing call holds its worker

regardless of how the server dispatches. Synchronous slow I/O on the request path is a trap in any

threaded runtime, ours included.

The fix isn't a bigger thread pool — it's not doing the slow work on the request at all. LOOK ships

a persistent, SQLite-backed job queue in core. The route calls jobs::push(...) and returns

instantly; a separate worker process drains the queue and does the slow send out-of-band, with

retries and crash-safety. Re-measured: 8 concurrent orders, homepage still responds in ~2 ms.

route("POST", "/order", function() {
    save_order();
    jobs::push("mail", json::encode(payload));   // returns now
    return response::redirect("/thanks");
});

WordPress's synchronous wp_mail can't do this without bolting on Redis and a queue library. In

LOOK it's built in — minimal external runtime dependencies, one binary. The measurement is the

point: we didn't assume our model was safe, we probed it until it broke, and then we shipped the

pattern that keeps a real site up when the mail gateway isn't.