Cookie Preferences
We use cookies to enhance your experience, analyse site traffic, and support our marketing. You can customise your preferences or accept all cookies. See our Privacy & Cookie Policy for details.

Multi-Cloud Architecture

Serverless Cold Starts Are a Design Problem, Not a Platform Limitation

Multi-Cloud Architecture

5 min read

Cold start latency gets blamed on the serverless platform far more often than it gets traced to the function's own design — package size, dependency weight, and initialisation work the function does on every cold invocation.

Most of the levers that actually reduce cold start time are in the application's control, not the platform's, which is good news for anyone willing to do the design work instead of switching platforms.

Where the latency actually comes from

Large deployment packages, heavy dependency trees loaded at startup, and database connections established on every cold invocation are the usual suspects — all addressable at the application layer, none of them platform limitations in the way they're often described.

Measuring cold start time with a profiler, rather than assuming it's inherent to the platform, usually reveals the real culprit within minutes.

Design changes that genuinely help

Trimming the deployment package to only what's needed at runtime, lazy-loading non-critical dependencies, and using connection pooling patterns designed for serverless lifecycles reduce cold start latency far more reliably than switching providers in search of a faster platform.

Most cold start complaints are a profiling exercise away from a design fix, not a platform migration.MNB Cloud Practice

Key actions

  • Profile cold start time before assuming it's a platform limitation
  • Trim deployment packages to only runtime-necessary dependencies
  • Lazy-load non-critical dependencies on invocation
  • Use connection pooling patterns designed for serverless lifecycles

Discuss this with an architect →