Design Serverless Platform

Problem Statement: Serverless Platform Design

Design a serverless platform (internal PaaS or multi-tenant FaaS) that lets teams deploy versioned functions triggered by HTTP, queues, schedules, and cloud events—without managing servers. Interviewers expect you to separate the control plane (registry, routing, quotas, deploy API) from the data plane (sandboxed runtimes, concurrency pools, event ingress). A strong answer states who owns the platform (central platform vs product squads), how releases promote across dev/stage/prod, and what "done" means: P99 invoke latency under SLO, predictable cold-start bounds, and hard multi-tenant isolation when one function misbehaves.

Interview Focus

• Separate control-plane APIs from ephemeral execution sandboxes
• Quantify invocations/sec, concurrency, and cold-start budget before picking runtimes
• Layer tenant isolation: IAM, network, quotas, and runtime sandboxes
• Always articulate idempotency, DLQ behavior, and alias rollback

How to open this one

The framing that signals depth on a serverless platform is the cold-start-versus-utilization trade-off: functions scale to zero so you pay nothing idle, but pay a cold-start penalty on the first request — so the whole design is about hiding that latency with pre-warmed pools, snapshot restore, and concurrency limits. Lead with the request lifecycle from event to sandboxed invocation, and the failure story that matters: a traffic spike outruns scale-up and requests queue or throttle. That shows you understand where serverless wins and where it hurts.