Serverless Computing: Building Apps Without Servers

Every year, on the day a new Tatkal quota opens, IRCTC's booking search API sees something like this: for twenty-three hours and forty-five minutes, traffic idles at a background hum — people checking PNR status, browsing trains, the ordinary trickle of a large country going about its day. Then, at 10:00:00 AM sharp, request volume jumps two orders of magnitude in under a second, holds there for roughly fifteen minutes while lakhs of passengers race for a few thousand berths, and collapses back to the hum. Any engineering team that has ever owned this kind of workload has faced the same brutal question: how many servers do you keep running?

Provision for the 10:00 AM spike, and you are paying, every hour of every day, for capacity that sits almost entirely idle. Provision for the daily average, and at 10:00:00.001 AM your service falls over exactly when it matters most. Serverless computing exists to dissolve this dilemma — not by making servers disappear, but by changing who owns the provisioning decision, and at what granularity the bill is calculated. That granularity turns out to be the whole story, and by the end of this chapter you will be able to compute, not just assert, why it matters.

What "serverless" actually means

Start with the misconception this term invites, because it is almost designed to mislead: serverless does not mean your code runs without a server. A physical or virtual machine, owned and operated by your cloud provider, executes every line of your function exactly as before. What has actually changed is the unit of deployment and billing.

Compare the three layers of cloud compute you have likely already met:

• IaaS (Infrastructure as a Service) — you rent a virtual machine. You choose the OS, patch it, decide how many instances to run, and pay for every hour each instance exists, whether or not it is doing useful work.
• PaaS (Platform as a Service) — you deploy an application to a managed runtime (think a web server process that a platform keeps alive for you). You no longer manage the OS, but the process is still "always on": one long-lived program waiting for requests.
• FaaS (Function as a Service) — the technical name for what people call "serverless" — you deploy a single function. There is no long-lived process that is "yours" at all. The platform allocates an isolated execution environment (in practice, a lightweight container or micro-VM) only when an event arrives that needs your function to run, executes exactly that one function call, and is free to destroy or reuse that environment afterward. If nothing is happening, your account is running zero instances of anything, and you are billed nothing for compute.

That last property — the ability to scale down to genuinely zero running instances between events, and scale up to thousands of concurrent instances within seconds — is the one traditional VM-based autoscaling cannot match, and it is the property that makes serverless the right tool specifically for bursty, low-duty-cycle workloads like Tatkal search, rather than for everything.

Serverless functions are triggered by events, not by an always-listening process you wrote. Common triggers: an HTTP request arriving at an API gateway; a message landing in a queue; a file being uploaded to object storage (the canonical example is an uploaded photo automatically triggering a thumbnail-generation function); or a scheduled timer, the serverless equivalent of a cron job. Your function's job is to react to one event and return — it is not supposed to hold open connections or run indefinitely, and most FaaS platforms enforce a hard ceiling on execution duration (commonly a handful of minutes, up to fifteen on the major public clouds) specifically to keep the model event-shaped.

The execution lifecycle: cold starts and warm containers

Here is the mechanism that everything else in this chapter builds on. When an event arrives for your function, the platform's router asks one question: is there already an idle execution environment for this function, warmed up from a previous invocation? Two paths follow:

Warm path. Yes — an environment exists, sitting idle since it finished its last invocation. The router hands the new event straight to it. The language runtime is already loaded, any module-level setup code (opening a database connection, loading a config file) already ran once and is cached in memory. Only your handler function executes. Dispatch overhead is small — typically single-digit to low double-digit milliseconds.

Cold path. No — every existing environment is busy, or none exists yet (first invocation ever, or first invocation after a new deployment). The platform must provision a fresh sandbox: allocate a container, mount your code package, start the language runtime, run your module-level initialization code, and only then call your handler. This is a "cold start," and depending on runtime and package size it commonly adds on the order of a few hundred milliseconds to a couple of seconds before your handler's own logic even begins — treat that figure as an illustrative order of magnitude, not a guaranteed number, since it varies by language runtime, package size, and provider.

This is also why experienced serverless developers move expensive setup — opening a database connection pool, loading a machine-learning model into memory — to module scope, outside the handler function. A cold start pays that setup cost once per environment; every warm invocation that reuses the same environment skips it entirely. Put the same setup code inside the handler by mistake, and you pay it on every single invocation, warm or cold.

Worked example: sizing the Tatkal spike with Little's Law

Let's make the opening scenario precise enough to compute. Model the IRCTC search API's traffic over one day as two regimes:

• Background: 50 requests/second, for 23 hours 45 minutes (85,500 seconds)
• Tatkal spike: 5,000 requests/second, for 15 minutes (900 seconds)

Step 1 — total daily requests.

background_requests = 50 req/s × 85,500 s = 4,275,000
spike_requests      = 5,000 req/s × 900 s   = 4,500,000
total_requests       = 4,275,000 + 4,500,000 = 8,775,000 requests/day

Step 2 — duty cycle. This is the single number that tells you whether a workload is "serverless-shaped." Duty cycle is the ratio of average load to peak load:

average_rate = total_requests / 86,400 s = 8,775,000 / 86,400 = 101.56 req/s
duty_cycle   = average_rate / peak_rate  = 101.56 / 5,000     = 0.0203  ≈ 2.03%

The system spends 98.96% of the day (85,500 of 86,400 seconds) running at just 1% of its peak rate, and its average load across the whole day is a mere 2.03% of peak. Any capacity provisioned to survive the spike sits almost entirely idle the rest of the time — this is exactly the shape of workload where paying per-invocation beats paying per-server-hour.

Step 3 — how many concurrent function instances does the spike actually need? This is a direct application of Little's Law from queueing theory, which you can state simply: if requests arrive at a steady rate λ and each one takes W seconds to handle, the average number of requests being handled at the same instant is

L = λ × W

Assume each search request takes W = 0.1 s to execute. Then:

Background: L = 50 req/s   × 0.1 s = 5   concurrent function instances
Peak:       L = 5,000 req/s × 0.1 s = 500 concurrent function instances

The platform must hold roughly 500 execution environments alive simultaneously during the spike — a hundred times the background concurrency — and it must reach that number within the first fraction of a second of the spike beginning. The first wave of requests that arrive faster than existing warm environments can absorb them will each trigger a fresh cold start (recall the cold path above); once the platform has spun up close to that ~500-environment pool, the remaining 4.5 million spike requests reuse those warm environments and run at warm-path latency for the rest of the fifteen minutes. When the spike ends, environments that receive no further invocations for roughly ten to fifteen minutes (a typical, provider-set idle timeout) are torn down, and concurrency drains back toward 5.

Diagram: one function invocation, start to finish

The economics: pay-per-invocation vs. pay-for-provisioned-capacity

Now put a rupee-and-cents (well, dollar) figure on the Tatkal scenario, using a representative FaaS pricing model: a small per-request fee plus a per-GB-second compute fee, where a GB-second is one gigabyte of allocated memory held for one second of execution. This mirrors how AWS Lambda, and equivalent services on other clouds, actually bill.

Serverless cost. Assume each invocation is allocated 128 MB (0.125 GB) of memory and runs for 0.1 s, at illustrative rates of $0.20 per million requests and $0.0000166667 per GB-second:

GB-seconds per request = 0.125 GB × 0.1 s = 0.0125 GB-s
total GB-seconds        = 8,775,000 × 0.0125 = 109,687.5 GB-s
compute cost             = 109,687.5 × $0.0000166667 ≈ $1.83
request cost              = (8,775,000 / 1,000,000) × $0.20 ≈ $1.76
total serverless cost      ≈ $1.83 + $1.76 = $3.58 / day

Traditional server, provisioned for peak, 24/7. If one always-on instance handles 200 req/s and costs $0.10/hour, surviving the 5,000 req/s spike safely at any moment requires 25 instances running around the clock:

instances needed for peak = 5,000 / 200 = 25
cost = 25 instances × 24 h × $0.10/h = $60.00 / day

That is 16.7× more expensive than the serverless number — the direct cost of insuring against a 15-minute spike by paying for it for 24 hours.

Traditional server, reactive autoscaling (best case). Suppose instead the traditional fleet keeps only 1 instance running in the background and scales up to 25 exactly for the 15-minute spike window:

background cost = 1 instance × 24 h × $0.10/h = $2.40
spike cost        = 25 instances × 0.25 h × $0.10/h = $0.625
total               ≈ $3.03 / day

Notice this is actually slightly cheaper than the serverless figure of $3.58. This is the honest, non-hand-wavy version of the comparison, and it is worth sitting with: serverless is not magically the cheapest possible option for compute; a perfectly-timed traditional autoscaler doing exactly the right thing would edge it out, because per-invocation billing carries a margin for the convenience and elasticity you're buying.

The catch is the word "perfectly-timed." Booting a new virtual machine — loading an OS image, attaching it to a load balancer, passing health checks — commonly takes on the order of a minute or more. A traditional autoscaler reacting to the Tatkal spike at 10:00:00 AM will not have 24 extra instances ready until well into the spike, during which requests queue up, time out, or get dropped. A serverless platform's environment provisioning (the cold start you modelled above) is fast enough, in the hundreds-of-milliseconds range rather than tens-of-seconds, to track that ramp acceptably. The real case for serverless on a workload like this is not "cheapest possible compute" — it is "the operational risk of getting the provisioning number wrong, in either direction, is removed," at a cost close to the theoretical best case. That trade is most valuable precisely when duty cycle is low, as calculated above (2.03%). As traffic becomes steadier and duty cycle rises toward 1, the balance tips back toward always-on infrastructure.

Statelessness, and why it matters

One more structural constraint follows directly from the lifecycle you traced above: because the platform may create, reuse, or destroy any given execution environment at will, and different invocations of the same function may run in different environments simultaneously (that is exactly what "500 concurrent instances" means), a serverless function cannot rely on anything written to local memory or local disk surviving to the next invocation, or being visible to a sibling invocation running concurrently. Any state that must persist — a booking record, a session, a running total — has to live in an external, shared system: a database, an object store, a cache. This is not a limitation bolted on for security theatre; it falls directly out of the fact that "the function" is a piece of code, not a running process you own, and the number of environments executing it at any instant is a number the platform is actively deciding, second to second, based on load.

Active recall

Attempt each question before reading its answer.

1. A background job runs at 80 req/s all day, except for a 10-minute daily batch window where it jumps to 2,000 req/s. Compute the duty cycle. Is this workload serverless-shaped?
2. Using Little's Law, if peak arrival rate is 1,200 req/s and each request takes 250 ms to execute, how many concurrent execution environments must the platform provision at peak?
3. Why does moving a database-connection setup from inside a function's handler to module-level (outside the handler) reduce typical latency under sustained load, but not fix the very first invocation's latency?
4. A team notices that every time they deploy a new version of their function, cold starts spike sharply even though total traffic hasn't changed. Why?
5. Based on the duty-cycle idea, describe a workload where a traditional always-on server would likely be cheaper than a serverless function doing the same job.
6. True or false, with justification: "A serverless function can reliably write a file to local disk and read it back during a later, separate invocation."

Answers

1. Average rate = (80 × 85,800 + 2,000 × 600) / 86,400 ≈ 93.3 req/s. Duty cycle = 93.3 / 2,000 ≈ 4.67%. This is well under 10% — a strongly serverless-shaped workload, same category as the Tatkal example.
2. L = λ × W = 1,200 × 0.25 = 300 concurrent execution environments.
3. Module-level code runs once per environment, when that environment is created (i.e., on a cold start), and its result is cached in memory for every subsequent warm invocation that environment serves — so warm-path latency drops because the connection setup is skipped. The very first invocation of a brand-new environment has no prior warm state to reuse; it must still pay the setup cost once, exactly like any cold start.
4. A new deployment replaces the code package, which invalidates every existing execution environment — they were built from the old code and cannot serve the new version. The platform must build a fresh pool of environments from scratch for the new version, so the first wave of post-deploy traffic (potentially the full concurrency the workload needs) hits cold starts simultaneously, even though the request rate itself never changed.
5. A workload with duty cycle close to 1 — steady, high, near-constant utilization all day, with little idle time to "scale down" into. Here the per-invocation/per-GB-second pricing premium is being paid on almost every second of the day with no offsetting savings from idle periods, so a reserved, always-on instance sized to that steady load is likely to undercut serverless on raw cost, as the reactive-autoscaling calculation above hinted.
6. False. Execution environments are ephemeral and not guaranteed to be reused; the very next invocation, even moments later, may be routed to a different environment (especially under concurrent load) or to a freshly cold-started one after the old environment was reclaimed. Local disk inside an environment (where writable at all) must be treated as a temporary cache for the current invocation's lifetime only — anything that must survive belongs in an external database or storage service.

Think About It

Think about this: How would you explain serverless computing: building apps without servers to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind serverless computing: building apps without servers, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.