Fat Controllers

app.post('/checkout', async (req, res) => {
  await db.transaction(async (tx) => {
    const cart  = await tx.cart.findUnique({ where: { id: req.body.cartId } })
    const tax   = await taxApi.quote(cart)        // ~200ms, someone else's p99
    const fraud = await fraudApi.score(cart)      // ~150ms
    const charge = await stripe.charges.create({  // ~500ms, sometimes 8s
      amount: cart.total + tax.amount,
    })
    await tx.order.create({ data: { chargeId: charge.id } })
    await mailer.sendReceipt(cart.email)          // in the request path too
  })
  res.status(201).json({ ok: true })
})

app.post('/checkout', async (req, res) => {
  const cmd = parseCheckout(req)                  // untrusted -> typed
  const result = await checkout(deps, cmd)
  res.status(result.ok ? 201 : STATUS[result.reason]).json(toBody(result))
})

async function checkout(deps, cmd) {
  const cart   = await deps.carts.find(cmd.cartId)          // no transaction yet
  const tax    = await deps.tax.quote(cart)                 // outside
  const fraud  = await deps.fraud.score(cart)               // outside
  if (fraud.reject) return { ok: false, reason: 'rejected' }
  const charge = await deps.payments.charge(cart, tax, cmd.idempotencyKey)

  return deps.db.transaction(async (tx) => {                // milliseconds
    const order = await deps.orders.insert(tx, cart, charge.id)
    await deps.outbox.append(tx, 'order.placed', order.id)  // email via the outbox
    return { ok: true, order }
  })
}

In the first version each in-flight checkout holds one of a fixed number of pooled connections for roughly 850 ms of someone else's latency, so a 10-connection pool saturates at about a dozen concurrent checkouts and every other endpoint in the service starts waiting on the pool. In the second, the connection is held for the two inserts only — a few milliseconds — so the same provider slowdown makes checkout slow and leaves the rest of the service working. The email moves to the outbox because it must not be able to fail the order, and must not be re-sent when the request is retried (The Transactional Outbox).

1. 1
   Parse

   Turns the untrusted request into a typed command, rejecting what cannot be meaningful (Parse, Do Not Validate).

   fails by Passing req.body onward unparsed, so every layer below re-checks or trusts it (Mass Assignment and Over-Posting).

2. 2
   Establish the actor

   Resolves the authenticated principal and the tenant from verified credentials, never from the body (The Trust Boundary).

   fails by Reading body.tenantId; or checking authentication and calling it authorization (Authentication vs Authorization).

3. 3
   Delegate

   Calls one application function with the command and the actor.

   fails by Doing the work here instead — the fat version; or calling six functions and orchestrating them, which is the same thing spread out.

4. 4
   Map the result

   Turns a domain result into a status code and a response body (Status Codes From the Server's Side).

   fails by Returning internal error text or the raw ORM entity (Not Leaking Your Internals, Schema Leakage).

Cross-cutting concerns — logging, correlation id, rate limiting, error mapping — are not steps in this list because they belong to the pipeline around it (The Middleware Pipeline).