Serverless Architecture
Fully managed, event-triggered compute where you ship functions rather than servers. This area covers the execution model, triggers, cold starts, forced statelessness, managed backing services, and the very different cost curve.
part ofSoftware design & architectureoverview, primer and where to startread it →on this pageshowhide
explore
- Functions as a Service5 questions
- Event Triggers6 questions
- Cold Starts6 questions
- Statelessness & State Management6 questions
- Managed Backend Services5 questions
- Cost & Scaling Model6 questions
questions
page 2 of 2You're designing cost and capacity governance for an organization running dozens of serverless functions that share a single account-level concurrency limit and several downstream dependencies with their own capacity ceilings (e.g., a relational database, a rate-limited third-party API). What's your approach to preventing one function's traffic pattern from silently degrading cost or reliability for the rest of the account?
basics
~10 sGive critical functions a guaranteed slice of shared capacity, cap risky/bursty ones so they can't eat everything, protect fragile downstream systems like databases with pooling or their own limits, and monitor the shared pool.
A scheduled (cron-style) trigger fires a serverless function every 5 minutes to reconcile a data feed, and each run typically takes about 4 minutes. What can go wrong if the schedule doesn't account for overlapping executions or missed invocations, and how would you design around it?
basics
~20 sIf a run takes almost as long as the gap between runs, sometimes the next run starts before the last one finishes, and now two copies are working on the same data at once, which can cause conflicts or double work. You need a way to stop overlapping runs and a plan for what happens if a run is skipped entirely.
Different FaaS platforms manage instance concurrency differently - AWS Lambda by default routes exactly one invocation to an execution environment at a time, while Google Cloud Functions gen2 (built on Cloud Run) and Azure Functions can be configured to handle multiple concurrent invocations per instance. What are the practical implications of this difference for how you write handler code and size downstream connection pools?
basics
~20 sSome FaaS platforms give each running function instance exactly one request at a time, while others let a single instance handle several requests at once, similar to a small web server. That difference changes whether your code needs to worry about two requests running at the same time inside the same process, and how many database connections your system ends up opening.
A stateless serverless API scales out to 3,000 concurrent function instances during a traffic spike, and each instance opens its own connection to a relational database used as the externalized state store. What failure results, and what architectural patterns address it?
basics
~20 s3,000 function copies each opening their own database connection can overwhelm the database's max-connection limit, causing connection errors; the fix is a shared connection pooler between the functions and the database, or a database designed for many simultaneous connections.
showing 31–34 of 34