---
title: Why the User Should Never Wait for Things They Cannot See
description: "Confirmation emails, document generation, analytics — none of these should block the booking screen. Background jobs keep the experience fast and the plumbing reliable."
canonical: https://nowah.xyz/blog/background-jobs-user-never-waits
lastModified: "2026-08-07T08:32:22.010Z"
---

# Why the User Should Never Wait for Things They Cannot See

Confirmation emails, document generation, analytics — none of these should block the booking screen. Background jobs keep the experience fast and the plumbing reliable.

A user just confirmed a booking. The moment they tap "confirm," they should see the booking confirmation instantly. They should not wait for the confirmation email to send. They should not wait for the trip document to generate. They should not wait for the analytics event to log.

The principle is simple: if the user does not need to wait for it, they should not wait for it.

## What happens in the background

![Illustration for this section](https://pics.nowah.xyz/website-media/founder-066-img-1.webp)

After every booking, a cascade of downstream tasks executes: confirmation emails, [push notifications](/blog/launching-push-notifications-travelers-informed), document generation, analytics aggregation, trip view updates, and more. Each of these is important. None of them needs to happen synchronously.

Our architecture uses seven background job queues, each handling a different category of async task. When a booking confirms, the user sees the confirmation immediately. The downstream tasks are dispatched to their respective queues and processed reliably in the background.

The queues are backed by an in-memory data store with automatic retry on failure. If a confirmation email fails to send, it retries. If a document generation times out, it retries. The user never knows because the retries happen silently. The system is self-healing for transient failures.

## Why this makes the product feel fast

Every millisecond between the user's action and the visible result contributes to the perception of speed. If the booking confirmation takes two seconds instead of half a second because the system is waiting for an email to send, those additional seconds feel like lag.

By moving all non-essential work to the background, the critical path, the thing the user is waiting for, is as fast as possible. The booking confirmation appears in under a second. Everything else happens afterward, reliably but invisibly.

## The infrastructure

![Supporting diagram](https://pics.nowah.xyz/website-media/founder-066-img-2.webp)

Seven queues handle different task categories: email delivery, push notifications, document generation, analytics, trip updates, webhook processing, and general-purpose tasks. Each queue has its own concurrency settings, retry policies, and failure handling.

Dead-letter queues capture tasks that fail after all retries, ensuring nothing is silently lost. Monitoring tracks queue depth, processing time, and failure rates. If any queue shows signs of backing up, alerts trigger before it affects users.

## Speed as a design philosophy

Speed is not an optimization we apply after building features. It is a [design philosophy](/blog/design-philosophy-invisible-technology) that shapes how we build every feature. The question is always: what is the minimum the user needs to wait for? Everything else moves to the background.

Every millisecond of waiting you eliminate is trust you build. The user experiences a product that feels responsive and reliable. The infrastructure that makes it possible is invisible, as it should be.

---

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).