As an engineering lead, how would you set policy for which runtime target your organisation's web apps deploy to?
answer
- capability matrix before host names
- one default, written exceptions
- portability is bought, not free
- conformance test per target
- revisit on triggers, not calendar
basics
~20 sStart from a capability matrix of what each target shape can do, name one default target, require a written exception to leave it, and gate every target with a conformance test, because mismatches degrade silently.
solid answer
~40 sPolicy should be capability-first, not preference-first. Write down what each shape provides — request-time rendering, streaming that flushes as it writes, storage all instances reach, long-held connections, request-time asset CPU — and what each app actually uses. Most organisations then pick **one default target** that covers the majority, with a documented exception path for the apps that genuinely need another. Two things make or break it. First, **portability has a price**: writing every app to the narrowest shape keeps you movable and costs features, while exploiting one host's extras is faster now and pins you later — decide that deliberately. Second, **the failure mode is silence**, so each target needs an automated conformance check that exercises streaming, regeneration and cache behaviour against the real shape. Revisit on triggers, not on a calendar.
go deeper
Understand the shape of the decision: targets differ in what they can do, so the app's needs come first and the host second. You are not expected to set this policy, only to know it exists.
Be able to fill in the capability matrix for the app you work on — what it needs at request time, what state it shares, whether it streams — and say which target shapes that rules out.
Argue for a default plus explicit exceptions, and insist on a conformance check per target, because target mismatches degrade silently. Bring the operational cost of each extra shape into the discussion.
Own the portability tradeoff explicitly and say who runs each approved shape. Define the triggers that reopen the decision, and separate genuine capability arguments from team comfort so both are weighed honestly.
Choosing a runtime target once, for one app, is an engineering decision. Setting it as policy for many apps and teams is a different problem: you are choosing what the organisation may rely on, how much divergence you will pay for, and how you will find out when a target stops fitting. ## Start from capabilities, not from hosts The durable artefact is a matrix of **capability against target shape**, filled in for the shapes actually on the table. | Capability the app may need | Long-running process | Per-request functions | Edge runtime | File host | |---|---|---|---|---| | Rendering at request time | yes | yes | limited by the runtime's API surface and CPU budget | no | | Streaming a response as it renders | yes, if nothing in front buffers | depends on the platform and proxy | usually yes | no | | Regeneration of prerendered pages | yes, with a store all instances reach | same, and unavoidable there | same | no | | Server-side data cache shared by users | yes, with a shared store | yes, with a shared store | yes, with a shared store | no | | Holding a connection open | yes | bounded by invocation duration | usually bounded | no | | Request-time image or font work | yes, at CPU cost you own | yes, at cost per invocation | usually not viable | no, precompute it | | Work continuing after the response | yes | unreliable | unreliable | n/a | Then do the same for the portfolio: for each app, which of those rows it truly uses. The overlap is the answer. Most organisations discover that the majority of apps use a narrow set, and that a small number of apps drive every exotic requirement. ## Pick a default and make exceptions explicit 1. **One default target** that covers the majority, chosen so that teams who think about nothing get something sensible. 2. **A written exception** for any app that leaves it, naming the capability the default cannot provide and who will operate the alternative. 3. **A per-target ownership answer.** A second shape is a second set of runbooks, alerts and on-call knowledge. If nobody owns it, the exception is not really approved. The aim is not uniformity for its own sake — it is that divergence is a decision somebody made, rather than the residue of whoever set up a pipeline first. ## Price portability deliberately This is the judgement call the rest of the policy hangs on, and it has no universally right answer: - **Write to the narrowest shape you might ever need.** Apps stay movable, target changes are cheap, and every team pays permanently in features they cannot use and libraries they cannot adopt. - **Exploit what the chosen host provides.** Teams move faster now, and a future move becomes a project rather than a config change. A workable middle is to restrict the constraint to the layer that matters: keep the *contract* portable — the build output shape, where state lives, what the app assumes about instance lifetime — and let teams use host conveniences above that line. What you must not do is leave it implicit, because the default outcome is deep coupling nobody chose. ## Gate every target with a conformance check The recurring lesson of target mismatches is that they **do not fail the build**. A cache that never hits, a stream that arrives in one chunk, a regenerated page that reverts, post-response work that runs sometimes — all of these look like a healthy deploy. So the policy needs an automated check per target that runs against the real shape, not a development server: - request a cacheable route repeatedly and assert the origin was not hit each time; - trigger a regeneration and read the page back enough times to cross instances; - measure time-to-first-byte on a streamed route against the full-body time; - exceed a duration limit deliberately and assert the behaviour is the one you documented; - assert the size of anything bound for a constrained runtime, so dependency growth fails the pipeline rather than the deploy. Make the check part of the target definition. A target nobody has a conformance run for is not an approved target. ## Decide when to revisit Calendar reviews produce paperwork. Triggers produce decisions: an app needs a capability the default lacks; the operational cost of a second shape exceeds the value it was approved for; traffic shape changes enough that per-request cost and a standing process swap positions; a conformance check starts failing after a host changes behaviour. ## What to watch for in the room Two failure modes dominate this conversation. One is **choosing the target from a benchmark** — a number produced on a workload that resembles nobody's app. The other is **choosing it from where the team is comfortable**, which is a real input but a weak reason on its own; comfort is worth naming out loud so it can be weighed against capability rather than dressed up as one.
- How do you keep a second approved target from quietly becoming unowned?Tie approval to ownership. The exception names who runs that shape, who is paged for it, and where its runbook and conformance check live. Review the list when people move teams; a target whose owner has left is either re-owned or its apps migrate back to the default.
- What would make you split one app across two target shapes?A small number of routes needing something the default cannot do — typically long-held connections or heavy request-time CPU. Routing a few paths to a second shape is usually far cheaper than redesigning the app, but it doubles the operational surface, so it is worth doing only when the affected routes are genuinely few and stable.
- Is standardising on the narrowest shape the safe default for a large portfolio?Not automatically. It maximises movability and minimises surprise, and it taxes every team forever in capabilities and library choices. It suits organisations that expect to move hosts or run in several environments; where that is unlikely, the tax buys an option nobody exercises.
saying these in an interview costs you the question
- Picks a target from a benchmark rather than required capabilities
- Assumes a green build proves the target supports every feature
- Approves a second target with nobody owning its operations
- Treats portability as free instead of a priced tradeoff
- Sets the policy once and never names a revisit trigger