Serverless Architecture

A cold start is the extra delay when a serverless function runs for the first time (or after being idle) because the cloud provider has to set up a fresh container and boot the code before it can process the request, instead of reusing one that's already running.

You pay for two things: how many times your function ran (per request), and how much compute it used each time (memory allocated multiplied by how long it ran, in GB-seconds). No traffic means no bill.

Push: the source (like an API Gateway) calls the function immediately for each request, so it runs right away. Poll: the platform itself checks a source (like a queue) on a timer, gathers waiting messages, then invokes the function with a batch.

A cold start is when the cloud has to build a fresh environment to run your function, which takes extra time. A warm start reuses an environment left over from an earlier call, so it responds almost instantly.

Because each request might land on a different, freshly-started copy of your function that never saw that variable, so the data would just be missing sometimes.

Cognito checks who the user is, DynamoDB stores the order data, and when a new order is saved, a small event rule automatically tells EventBridge/SNS to notify the shipping partner — no server is running in between.

A cold start has three parts: finding a machine and starting an isolated sandbox, booting the language engine (like the JVM or Python interpreter), and running your own startup code (imports, DB connections). For Python it's usually your own code and the interpreter that dominate; for Java it's usually the JVM and framework startup.

It's a cap on how many copies of your function can run at once. If more requests arrive than the cap allows, the extra ones get rejected or queued/retried instead of running immediately.

The client is waiting live, so the function has to answer fast — there's a hard time limit shorter than the function's own max runtime. If it's too slow or crashes, the gateway just returns an error straight to the client; nothing retries automatically.

Normally, if any message in the batch fails, the whole batch of 10 gets retried later — including the 7 that already succeeded, so they run twice. Partial batch response lets the function tell the queue exactly which 3 failed, so only those get retried and the other 7 aren't repeated.

Code written outside the handler function runs once per environment and gets reused across many warm calls, while code inside the handler runs every single time. Putting slow setup (like opening a connection) outside means later calls skip that work and run faster.

/tmp is just a scratch disk attached to one function instance; it disappears when that instance is recycled, and other instances never see it, so it can't reliably hold data you need to keep.

Lock-in comes from writing your app's rules and data shape in the vendor's specific style. Some things (like standard login tokens) transfer easily; your database's exact structure and vendor-specific security rules usually don't, so leaving means real rewrite work.

Provisioned concurrency pays to keep a set number of function instances pre-warmed and ready at all times, so requests hit already-initialized code instead of waiting for a fresh one to boot — but you pay for that idle readiness even when there's no traffic.

Serverless wins when traffic is spiky or low-volume, since you pay nothing while idle. An always-on server wins when traffic is steady and high, since its flat rate beats serverless's per-request premium at high utilization.

That one shard gets stuck: every batch keeps re-trying starting from the same bad record, so new records behind it never get processed — like a traffic jam on one lane. Other shards each have their own separate reader, so they keep moving fine; the jam doesn't spread.

A cold start is slow because the platform has to boot a brand-new environment: download your code, start the language runtime, and run any setup code before your function can even begin. All major clouds let you pay extra to keep a pool of environments pre-warmed and ready, so real users never hit that slow first call.

Keeping progress in a running function's local variables means a crash or timeout loses everything and forces starting over, possibly repeating things like a payment charge; a workflow orchestrator instead saves each step's result externally so the process can resume exactly where it stopped.

SNS pushes a message to every subscriber, full stop. EventBridge lets you write rules that pick which events go where based on their content, so it's easier to plug in new, unrelated consumers later without touching the publisher.

A scheduled ping keeps one instance warm, but real traffic often needs many instances at once, and pings can't predict or prevent the cold starts that happen when demand suddenly scales up beyond what's already warm.

Reserved concurrency carves out a guaranteed, capped slice of the shared pool for one function only. Unreserved concurrency is the leftover shared pool every other function draws from.

FaaS functions have two hard caps: how much memory (and therefore CPU) you give them, and how long they're allowed to run before the platform kills them. If a function tries to use more memory than allowed it crashes, and if it runs past its time limit it gets forcibly stopped - so long or heavy jobs must be split into smaller pieces or moved to a different kind of compute.

DynamoDB/Redis are built for fast lookups of small structured records, while S3 is built for storing large files cheaply; picking the wrong one costs you either speed, correctness, or money.

SnapStart boots and initializes your function once, then saves a memory snapshot of that fully-warmed state; every future cold start just restores from that snapshot instead of re-running startup, making it much faster. The catch: cached state from before the snapshot (like random numbers or timestamps) can leak into later invocations unless you handle it explicitly.

When idle, the platform fully shuts down your function's instances, so you pay nothing. The catch: the next request after idle has to wait for a fresh instance to start up — that delay is a cold start.

At-least-once means the same upload event might trigger your function more than once, so it can't assume it only runs exactly one time per file. Events also might not arrive in the exact order files were uploaded, and there can be a short delay before the event fires.

Both invocations read the same starting number before either wrote back, so one increment silently overwrites the other and the counter ends up one short. DynamoDB fixes this with atomic updates or conditional writes that check the value hasn't changed.

BaaS tools are great for simple apps, but this project needs complex multi-step transactions, guaranteed EU-only data storage, and predictable costs at huge scale — things Firestore-style services aren't built to guarantee, so a traditional or hybrid backend fits better.

Most requests hit already-warm functions and look fast, so the average looks great, but the rare slow ones (cold starts) show up only in the tail (p99, the slowest 1%). Fixing that tail needs more than just averages — options include keeping capacity pre-warmed, timing out and retrying to a warm instance, or picking faster-starting runtimes.