// Architecture Styles · 08
Serverless
Write the function; the cloud runs, scales and bills it per use.
How it fits together
- Partner system creates imports bucket (uploads CSV)
- imports bucket publishes / notifies ImportCsv function (triggers)
- ImportCsv function uses / calls SQL database (upserts rows)
- ImportCsv function fails / error path Poison queue (fails 5 times)
Spot it
- Servers sit idle most of the day
- Traffic arrives in sharp, rare bursts
- Glue code reacting to files and queues
It costs
No servers to manage, but cold starts, time limits and vendor lock-in.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
The provider owns servers, scaling and patching; you deploy functions bound to triggers (HTTP, queue, timer, file upload) and pay for executions rather than uptime, on platforms such as AWS Lambda, Azure Functions or Google Cloud Functions. Managed queues, storage and databases complete the picture.
It fits bursty, event-driven or low-traffic work. It fits poorly for steady high load, where reserved compute is cheaper, for long-running or latency-critical work hurt by cold starts, and for anything that keeps state in memory between calls.
Serverless is a hosting model, not a code structure: a set of functions still needs clear boundaries, and many tiny functions can turn into a distributed monolith. It is a natural host for event-driven consumers.
Ask for it
- Function as a Service
- event trigger
- cold start
- scale to zero
- pay per execution
- execution timeout
Move this nightly CSV import from a VM into a function triggered by an upload to object storage. Keep it stateless and idempotent so retries are safe, and route repeated failures to a poison queue. Estimate pay-per-use cost versus the VM.