How do I decide which backend tasks should go serverless?

A good rule: make a task serverless when it’s event-driven, spiky, stateless, and tolerant of platform constraints.

Here’s a practical way to decide.

Great candidates for serverless

Use serverless for backend tasks that are:

• Triggered by events
  • HTTP requests, queue messages, file uploads, cron/scheduled jobs, DB changes, webhooks
• Short-lived
  • Usually completes in seconds to a few minutes
• Stateless
  • Doesn’t need local memory between runs
• Intermittent or unpredictable
  • Traffic spikes, low-frequency jobs, bursty workloads
• Easy to retry
  • If a job can run again safely, serverless fits well
• Simple to isolate
  • A single business action like “resize image,” “send email,” “validate input,” “sync record”

Examples:

• Image/video thumbnail generation
• PDF report generation
• Email/SMS sending
• Webhook processing
• Scheduled cleanup jobs
• ETL steps and queue consumers
• File processing after upload
• Lightweight API endpoints

Poor candidates for serverless

Avoid serverless when tasks are:

• Long-running
  • Exceed function time limits or need continuous processing
• Stateful
  • Need in-memory session state, open connections for a long time, or local disk persistence
• Latency-sensitive with cold-start pain
  • Especially if every millisecond matters and traffic is steady
• Compute-heavy for extended periods
  • Large jobs, ML training, media transcoding at scale, big data processing
• Need custom runtimes or OS-level control
  • Specialized networking, low-level system access, unusual dependencies
• Require strong transactional coordination across many steps
  • Often better in a service/workflow engine than ad hoc functions

Questions to ask for each task

Use this checklist:

1. What triggers it?
   • If it’s an event, good sign.
2. How long does it run?
   • If often near platform limits, reconsider.
3. Does it keep state?
   • If yes, probably not serverless without redesign.
4. How often does it run?
   • Rare or bursty = good.
5. Can it be retried safely?
   • If yes, easier to adopt serverless.
6. What are the peak and average loads?
   • Big difference between them favors serverless.
7. Any dependency on local resources, fixed IPs, or long-lived connections?
   • These can be problematic.
8. Do you need predictable always-on performance?
   • If yes, containers/VMs may be better.

A simple decision rule

Serverless is usually a good fit if the task is:

“An independent unit of work that starts from an event, finishes quickly, and can be retried without much pain.”

Common architecture pattern

Often the best approach is hybrid:

• Serverless for edge tasks, async jobs, and bursty workloads
• Containers/VMs for core services, persistent workers, and long-running processes

For example:

• API service in containers
• Upload processing in serverless
• Scheduled cleanup in serverless
• Heavy data pipeline in containers or managed batch services

Watch out for hidden costs

Serverless can look cheaper but may add:

• Cold starts
• Debugging complexity
• Vendor lock-in
• Orchestration overhead
• Higher cost for steady high-throughput workloads
• Limits on execution time, memory, concurrency, and package size

Practical recommendation

Start by migrating tasks that are:

1. Async
2. Idempotent
3. Short
4. Bursty
5. Low operational risk

That gives the best chance of serverless being a win.

If you want, I can also give you a decision matrix or help classify your specific backend tasks one by one.