Skip to content

Infrastructure & Integrations

Serverless and edge functions: where the work fits, not everywhere

Functions that run only when called are good at short work that comes in bursts. Code that runs near the visitor is good at tiny decisions made on every visit. Neither is good at a twenty-minute job or a backend that's busy all day. We decide where each piece of work runs by what it is, so you get the benefits without scattering your system across a hundred small pieces.
Talk through where things runSee where each kind of work fits ↓
near the visitoredgeon demandfunctionsalways onserver and workers212 old addressesredirect · tiny, every visitpayment provider's noticeshort · comes in burstsoffice app backendbusy all day · holds connectionsvisitor's service areadecided before the page loadsmonthly plan renewalsruns 20 min · on a workermonthly plan renewalsstopped at the time limit

Where each kind of work fits

Near the visitor (edge)a small decision on every visit: redirects, picking a region, checking a sign-init needs the database or more than a moment
On demand (functions)short work that comes in bursts: notices from other systems, form handlingit runs for minutes, or all day without pause
Always on (servers and workers)a busy backend, long jobs, steady connections to the databaseit's idle most of the day; you'd pay for waiting

What to watch for

Functions are easy to start with. These are the costs that show up later.

  1. 01

    The first-request wait

    After a quiet spell

    A function that hasn't run for a while takes longer to answer the first time. Fine for a notice, noticeable on a page.

  2. 02

    Time limits

    Long work gets stopped

    Functions are stopped after a set time. Anything longer belongs on a worker.

  3. 03

    Database connections

    Many short visitors

    Hundreds of functions each opening a connection can overwhelm a database. Pooling has to be planned.

  4. 04

    Scattered code

    A hundred small pieces

    Rules split across many functions drift apart. Shared rules stay in the backend; functions call it.

  5. 05

    Cost at volume

    Cheap when quiet, not always when busy

    Steady heavy work often costs less on an always-on server.

One payment notice, handled

A good fit for a function: it arrives without warning, needs a quick answer and is done in under a second.

Payment provider · invoice INV-2301 paid

  1. Notice arrives

    the function starts

    done

  2. Checked

    really from the payment provider, signature valid

    done

  3. Seen before?

    no; recorded once by its notice ID

    done

  4. Invoice marked paid

    through the backend, the one place that rule lives

    done

  5. Answered

    “received”, so the provider doesn't send it again

    done

Paid in the office app within seconds; a repeated notice would change nothing.

A function for everything, or functions where they fit

A function for everything

  1. 01Every feature its own function
  2. 02Long jobs split to fit the time limit
  3. 03Business rules copied between functions
  4. 04The database struggling with connections

The system is everywhere and nowhere, and nobody can see how it fits together.

Functions where they fit

  1. 01One backend for the rules and records
  2. 02Functions for short, bursty work that calls it
  3. 03Edge code for tiny decisions near the visitor
  4. 04Workers for long jobs

Each piece runs where it's cheapest and simplest to run.

What functions sit between

In

Visits
every page request
Notices
from payments and other systems
Form submissions
from the website
Functions and edge
small, short, on demand

Out

Redirects and page choices
near the visitor
Backend calls
where the rules live
Queued work
anything long

Worth using when the work is short, bursty or near the visitor

Good fit

  • Other systems send you notices at unpredictable times.
  • Visitors need a fast decision before the page loads.
  • Traffic is quiet most of the day with occasional spikes.

Not the right fit

  • Long-running jobs. They belong on workers.
  • A backend that's busy all day. An always-on server is simpler and often cheaper.

Where this capability is used

Next to functions

Questions about serverless and edge functions

Is serverless cheaper?

For work that's quiet most of the time, usually. For steady, heavy work, an always-on server often costs less. We look at how your work actually arrives before choosing.

Does serverless mean there are no servers?

No. The hosting provider runs the servers and starts your code when it's needed. You don't manage the machines, but they're there.

Will this lock us in to one hosting provider?

Some edge and function features are specific to a provider. We keep business rules in ordinary code in the backend, so the parts that would need rewriting to move are small.

Can our whole app be serverless?

Small apps often can. As an app grows, the busy backend and long jobs usually move to always-on servers and workers, with functions kept for what suits them.