The confirmation email makes checkout slow

You asked

“Checkout p95 is 2.4 s and 1.8 s of it is the email provider. Can you get the email off the critical path?”

The model answered

1app.post('/checkout', async (req, res) => {
2  const order = await createOrder(req.user.id, req.body.cart)
3  await chargeCustomer(order)
4 
5  // do not block the response on the email provider
6  sendEmail({
7    to: req.user.email,
8    template: 'order-confirmation',
9    data: { orderId: order.id },
10  })
11 
12  res.status(201).json({ orderId: order.id })
13})

Assistant · I removed the await on sendEmail, so the response returns as soon as the order is created and charged. The email still goes out in the background, and checkout latency drops by the full provider time.

Classify each statement

0/8 classified. Some statements are true — the point is telling which.

The HTTP response no longer waits for the email provider.

Under a checkout spike, the number of concurrent email sends in this process is limited only by the number of requests.

A failure inside sendEmail is not logged, counted or surfaced anywhere.

During a multi-hour provider outage, confirmations for every order placed in that window are affected.

A transient provider error results in one failed attempt and no second one.

Not awaiting the call is equivalent to running it in the background.

Whether the customer may occasionally receive two confirmation emails determines how the retry path must be designed.

An email whose promise is in flight when the process exits is never sent and never recorded as unsent.