15 OpenAI AI Engineer Interview Questions & Answers

I would create a stable run_id for every prompt run and store the run lifecycle, metadata, and ordered token progress on the server. If the user reloads the page, the client reconnects with the same run_id and the last received token offset. The server replays missing events and continues streaming new tokens if the run is still active. If the run already finished, the server returns the saved final result instead of starting generation again.

This question asks how an AI application can continue a prompt generation after a user reloads the page. The goal is to keep the same generation running and avoid losing progress or creating a second result.

1. Should recovery support only browser reloads, or also network disconnects and reconnects from another device?
2. How long should an unfinished prompt run remain available for recovery?

I would separate the temporary browser connection from the actual prompt run. When a user starts a generation, the application creates a unique run_id. This identifier stays the same throughout the run lifecycle.

The backend stores run metadata, current status, and the generated token stream. The token stream is stored as ordered events with increasing offsets. The browser connection can disappear, but the prompt run state remains available.

If the page reloads, the client reconnects using the same run_id and sends the last token offset it received. The server checks the stored stream state and sends only missing events after that offset. This prevents duplicate tokens and prevents lost output.

If the run is still active, the server continues streaming new tokens. If the generation completed while the user was away, the server returns the stored final result. If the user cancels the run, the backend updates the lifecycle state and stops generation.

The tradeoff is that storing run metadata and token events requires additional storage. The benefit is reliable recovery from browser failures and network interruptions without restarting expensive model work.

A common mistake is storing generation state only in browser memory because a reload removes that state. Another mistake is creating a new model request after reconnecting, which can produce different output and extra cost. Systems can also fail when they do not preserve token ordering, causing duplicate or missing tokens. Another mistake is treating completed runs as active streams instead of returning the saved final result.

Start with the main design decision: the browser connection and the prompt run should be separate. Then explain run_id, persisted state, replay using token offsets, active versus completed runs, and the main tradeoff.

I estimate the request usage locally, then atomically check both the user quota and the organization quota and reserve that estimate. If the reservation succeeds, I start model streaming immediately. Each accepted generation also reserves one concurrency slot. After the generation finishes, I compare actual token and cost usage with the reservation, settle the difference atomically, and release the reservation. This keeps exact reconciliation off the time to first token critical path while still protecting rate and cost limits.

The key idea is to do only the minimum admission work before calling the model. First, estimate how many input and output tokens the request may use and what that may cost. Then check both the user allowance and the organization allowance. If both have enough room, reserve the estimate in the same atomic operation. After that succeeds, start the model request and stream the answer. When the run finishes, compare the real usage with the reservation and correct the counters.

1. Are cost limits enforced for each user and for the whole organization?
2. Should short bursts be allowed when the normal rate is temporarily exceeded?
3. Should an over limit request be rejected, queued, or sent to a cheaper model?
4. Do we need a separate limit for concurrent generations?

I would keep local estimation and one fast quota reservation operation on the request critical path. Exact final accounting happens later.

First, estimate input tokens locally from the prompt. Reserve output capacity using the configured maximum output tokens. Estimate cost with separate input and output rates when those rates differ.

Next, run one atomic check and reserve operation. It checks the user limits, the organization limits, burst headroom, and the concurrency limit. If every check passes, it reserves the estimated token and cost budget plus one concurrency slot. Atomic means competing requests cannot both observe the same remaining quota and spend it twice.

User counters are tracked by user. Organization counters are shared by all users in that organization. This lets the service enforce both scopes together.

After reservation succeeds, persist a reservation record with the reservation identifier and reserved amounts, then start model streaming immediately. A renewable lease can protect against abandoned reservations after a crash. An active generation refreshes that lease so its quota is not released while work is still running.

If admission fails, return a rate limit response or apply an allowed degradation policy. The diagram shows options such as reducing the maximum output size, choosing a cheaper model, or queueing the request.

For bursts, a token bucket style allowance can permit short spikes while still enforcing usage over time. Concurrent requests still need the same atomic reservation so a burst cannot oversubscribe the budget.

After completion or cancellation, read actual input tokens, output tokens, and cost. Compare them with the reservation. If actual usage is higher, charge the extra amount. If it is lower, refund the unused reservation. Then release the concurrency slot and reservation. This reconciliation happens after streaming, so it does not delay the first token beyond the fast admission work.

1. Read the user identifier, organization identifier, selected model, prompt, and generation settings.
2. Estimate input tokens locally and reserve output tokens from the configured maximum output size.
3. Estimate reserved cost using the input rate and output rate.
4. Atomically check user limits, organization limits, burst headroom, and available concurrency.
5. If every check passes, reserve the estimated usage and one concurrency slot in that same atomic operation.
6. Persist a reservation record with the reservation identifier, user identifier, organization identifier, reserved input tokens, reserved output tokens, reserved cost, and concurrency slot.
7. Start model inference and stream tokens immediately after reservation succeeds.
8. If admission fails, reject the request or apply the configured degradation policy.
9. After completion or cancellation, obtain actual input tokens, output tokens, and cost.
10. Compare actual usage with the reservation and settle the difference atomically.
11. Release unused reserved capacity and the concurrency slot.
12. Use a renewable lease as crash recovery protection, and refresh it while the generation is active.

A common mistake is checking quota first and reserving later. Two concurrent requests can both pass the check before either updates the counters. Another mistake is using only a combined user and organization key instead of separate user counters and shared organization counters. It is also wrong to reserve tokens but ignore cost or concurrency. Another mistake is waiting for exact final usage before starting the response, which puts reconciliation on the streaming path. A fixed lease that expires during a valid long generation is also unsafe, so active reservations should refresh the lease and release it explicitly on completion or cancellation.

Explain the order clearly: estimate locally, atomically check and reserve both scopes, stream immediately after success, then reconcile actual usage. Emphasize that atomic reservation prevents concurrent overspending and that exact reconciliation stays outside the time to first token critical path.

I replay the bad request and inspect each RAG stage. I check candidate retrieval, reranking, final context, and generation separately. This tells me whether the chunk was missing, filtered out, or ignored by the model. Then I apply a targeted fix and add a regression test.

A bad RAG answer can fail at different stages. I first replay the exact user request and collect evidence from the pipeline.

1. Do we store logs for the query, retrieved candidates, reranker scores, final context, and model response?
2. Can we replay the same request with the same retrieval and generation settings?

First, I check retrieval. The question is: did the correct chunk appear in the candidate set? If not, retrieval failed. I inspect query rewriting, filters, metadata, chunking, embeddings, and index freshness.

Next, I check reranking and context assembly. The chunk may exist but be removed before reaching the model. I compare retrieved candidates with the final selected context and inspect reranker scores.

Finally, I check generation. If the correct information reached the prompt but the answer is wrong, the model may have ignored or contradicted the context. I inspect the final prompt, citations, and model output.

The fix should match the failed stage. A retrieval failure needs retrieval improvements, a ranking failure needs reranking changes, and a generation failure needs grounding or prompt improvements. Each fix should have a regression test.

1. Replay the exact failed request.
2. Check if the required chunk exists in retrieval candidates.
3. Check if reranking keeps the chunk in final context.
4. Check if generation follows the provided context.
5. Apply the stage-specific fix and add a regression test.

Debugging one request is usually fast if evidence is stored. Logging every stage increases storage cost but makes failures easier to diagnose. Regression tests add maintenance cost but prevent repeated failures.

Common mistakes include trusting retrieval metrics alone, changing prompts before proving the failing stage, and ignoring reranking or context assembly failures.

Explain the debugging flow from retrieval to generation. Focus on evidence, the first failing stage, the targeted fix, and the regression test.

At a high level, this system lets an agent use approved tools while keeping actions safe and controlled. The main challenge is allowing the agent to choose useful actions without giving unlimited access to real systems. I would explain it in three parts: the allowlisted tools and permissions, the real execution rules, and the safe simulation or replay flow. The trade-off is that stronger safety checks add more steps before write actions.

The goal is to let an agent use tools while making sure each action has the correct permission and can be reviewed later. The difficult part is balancing automation with safety because the agent can suggest actions, but it should not directly change important systems without rules. The solution is organized around approved tools, identity checks, execution controls, recorded observations, and offline simulation or replay.

1. Which tools are allowed for the agent, and which tools can change real data?
2. Which users or evaluators can run the agent, and what permissions should they have?
3. Should offline evaluation only simulate actions, or should it replay previous tool results?

At a high level, the agent should only use tools that it is allowed to call. The allowlisted tool surface defines these available tools. Each tool has a clear purpose, input format, and expected behavior. This prevents unknown actions from being executed.

The model can decide a possible action, but application code controls permissions. A model suggestion does not grant access by itself.

The system checks who is acting before a tool runs. The diagram shows user, agent, evaluator, and system identities. The authorization layer applies least privilege, which means giving only the access that is needed.

Read actions only view information. Write actions can change state, so they need stronger checks and approval. Tool contracts define names, arguments, effects, limits, and error behavior.

The agent sends structured arguments when it chooses a tool. The runtime checks the permission rules before execution. The execution environment contains read resources and write resources.

Read resources return information without changing state. Write resources can update systems such as user profiles, email services, or databases. Production changes only happen with authorized identities.

The system records tool calls and results. The records include the request, arguments, identity, permission decision, results, errors, and timestamps. This helps teams understand what happened.

Simulation can use mock tools or recorded data without real side effects. Replay can run previous requests again using saved observations. Both approaches help test agent behavior without changing production state.

The key safety boundary is between offline evaluation and production systems. Offline evaluation must not mutate production state. This protects important systems from accidental changes.

The benefit is safer testing and better auditing. The downside is that simulations may not perfectly match real systems, and permission checks add extra complexity.

The benefit is that the agent can automate tasks while following safety rules. Approved tools limit available actions. Permission checks protect important systems. Recording actions helps debugging and review. Simulation and replay allow testing without changing real data. The downside is that this design adds more checks before write actions. Offline simulations may also behave differently from real systems. We accept this because protecting production data is more important than making every test identical.

At a high level, the evaluation should turn evidence into one clear release decision for the agent. The hard part is balancing useful task performance with safety, uncertainty, and costly failures. I would explain it in three parts: compare the candidate with a baseline, check safety and task-success evidence, then choose rollout scope and rollback rules. The trade-off is that broader release creates more value, but it needs stronger evidence and lower uncertainty.

The goal is to decide whether a candidate agent should ship, stay on hold, or launch only to a limited group. The difficult part is that one overall score is not enough. The agent may work well on common tasks but fail badly on a high-cost slice. The evaluation therefore compares the candidate with a clear baseline, checks hard safety rules, measures task success by slice, looks at uncertainty, and then connects that evidence to rollout scope, owners, and rollback criteria.

1. What exact candidate agent and baseline are we comparing?
2. Which tasks, user groups, and failure-cost slices matter most?
3. Which safety failures are automatic hard blocks?
4. What minimum task-success threshold must each required slice meet?
5. What uncertainty is acceptable for a broad release?
6. How much rollout exposure is allowed, to whom, and for how long?
7. Who owns the release decision, safety approval, engineering work, and rollback?

I would start by making the comparison fair. The diagram compares Candidate agent A with Baseline B. Both should use the same task, data, and evaluation rules. This matters because a release decision only makes sense when we know exactly what changed. This step gives us a clear candidate-versus-baseline test.

Next, I would test the intended tasks and the people affected. I would also separate failure-cost slices into low, medium, and high impact. A slice is simply a group of cases that needs its own result. This prevents a good average score from hiding a serious failure in an important group.

Safety is a hard gate, not a score we can trade away. The candidate must pass all required safety policies and red-team checks. If any hard-block condition fails, the decision is HOLD. Better task performance cannot override that failure. This gives the evaluation a clear stop condition before broader rollout is considered.

If safety passes, I would check the primary success metrics and minimum thresholds. The candidate must meet or beat the baseline by the required margin on the required slices. Then I would look at confidence and variance. In simple words, I want to know how sure we are and how much the results change across data, time, and user segments. Weak evidence or high uncertainty can justify a limited release instead of a full ship.

The final decision is SHIP, LIMITED RELEASE, or HOLD. SHIP means all gates pass with strong evidence and acceptable risk. LIMITED RELEASE means some risk or uncertainty remains, so rollout stays controlled with monitoring. HOLD means a hard block failed or the evidence is not strong enough.

For SHIP or LIMITED RELEASE, I would define how much traffic is included, which users or regions are included, and how long the stage lasts. I would add guardrails, monitoring, and a staged rollout plan. I would name the decision owner, safety owner, and engineering owner, with sign-off for the chosen decision.

Finally, I would define rollback criteria before release. Triggers can include error rate, user harm, or policy violations. When a trigger fires, the rollback action should automatically return the system to the baseline, and the communication plan should notify the responsible owners. After fixes or more evidence, the candidate can be evaluated again.

The benefit is that the release decision is tied to clear evidence instead of one vague score. Hard safety blocks stop a release even when task results look strong. Slice-level checks also stop good averages from hiding costly failures. The downside is that stronger evidence takes more time and evaluation work. Uncertainty may remain even after testing. A limited release helps the team learn with less exposure. Rollback rules reduce risk after launch, but they need reliable monitoring, clear owners, and fast action when a trigger is reached.

At a high level, I would not release an agent based on task success alone. The main challenge is balancing quality with speed, cost, safety, and user effort. I would explain the decision in three steps: measure each outcome separately, apply hard guardrails that can block release, then compare the remaining objectives using justified normalization and weights. I would also report slices and uncertainty. The trade-off is that a combined score helps comparison, but it can hide important differences between users or tasks.

The goal is to decide whether an agent is ready for release without looking at task success alone. A useful agent must also respond fast enough, cost an acceptable amount, avoid unsafe behavior, and require reasonable effort from users. The difficult part is that these outcomes can conflict. A faster agent may cost more, while a cheaper agent may require more user corrections. The diagram handles this by measuring each outcome separately, comparing optimizable objectives, applying hard guardrails, reporting slices and uncertainty, and then making a clear release decision.

1. Which safety or compliance rules are strict release blockers?
2. Which objectives may trade off against each other?
3. Which user or task slices are important enough to inspect separately?
4. How much uncertainty is acceptable before we delay a release?

I would start with realistic tasks and users rather than one easy benchmark. The evaluation should include diverse scenarios, multiple user types, different tools and data, and adversarial cases. This matters because an agent can look strong on average while failing badly in one important situation. These workloads create the evidence used by every later release check.

Next, I would collect task success, latency, cost, safety violations, and user effort as separate results. Task success shows whether the agent completed the goal correctly. Latency shows how long users wait. Cost measures total expense per task. Safety captures policy problems or harmful outputs. User effort measures actions such as corrections and clarifications. Keeping these outcomes visible prevents one strong metric from hiding a serious weakness elsewhere.

These metrics use different units, so the diagram normalizes them to a common 0-to-1 scale. Normalization means converting different measurements into comparable scores. The direction must be consistent, so higher normalized values mean better results. A weighted score can then reflect product goals and risk appetite. The weights must add to one and should be transparent and justified. Robust rules, such as caps or logarithmic transforms, can limit the effect of extreme values.

Hard guardrails are non-negotiable release checks. If one fails, the release is blocked even when the weighted score looks strong. The diagram includes a safety violation threshold, zero tolerance for severe harm, a privacy leakage threshold, limits for tool misuse or policy breaks, and legal or compliance requirements. This ordering matters because safety and compliance should not be traded away for lower latency, lower cost, or higher task success.

Before deciding, I would inspect results by task type, user segment, geography or locale, and tool or data source. I would also report uncertainty using confidence intervals and sample sizes. This helps show whether an apparent improvement is reliable. It also prevents a strong overall average from hiding weak results for one important group.

If every hard guardrail passes and the weighted score meets its target, the agent can be released. If a guardrail fails or the score is below target, I would hold the release and iterate. A conditional release can be reasonable when the score is acceptable and there are clear mitigations, monitoring, and rollback plans. When dimensions conflict, guardrails come first. Among options that pass them, choose the strongest justified weighted result. After release, monitor for drift and document thresholds, weights, decisions, and lessons.

The benefit is that this process keeps one strong metric from hiding a serious weakness. Safety and compliance stay non-negotiable, while success, latency, cost, and user effort can be balanced more flexibly. The downside is that normalization and weighting require judgment. Different weights can change which candidate looks best. A combined score can also hide weak results for one user group or task type. That is why the diagram keeps the individual outcomes visible and also reports slices and uncertainty. Conditional release adds flexibility, but it requires monitoring, mitigation steps, a rollback plan, and clear documentation.

At a high level, I would keep the stream state so a user can continue an AI response after a mobile connection drops. The client starts a stream with a stream identity, and the Stream Service tracks ordered tokens and the last acknowledged offset. The service stores durable state and a bounded buffer for recovery. When the client reconnects, it sends the same identity and offset. The service validates the reconnect, resumes from the correct token, or explains when exact recovery is not possible. The trade-off is better reliability with extra state storage and cleanup work.

This question is about continuing an AI answer after a mobile network failure. The goal is to avoid losing the user's progress when the connection drops. The system needs to know what the user already received and safely continue from that point. The main challenge is storing enough state for recovery without keeping unlimited data. I will explain the design using the Mobile Client, API Gateway / Stream Service, LLM Provider, Stream State Store, and Bounded Buffer from the diagram.

• How long should a disconnected stream remain available for resume?
• Is partial replay acceptable when exact resumption is impossible?

The Mobile Client starts a stream with session_id, request_id, and stream identity. The API Gateway / Stream Service creates the stream and forwards the request to the LLM Provider.

The stream identity separates one AI response from another. It helps the service know which saved state belongs to the reconnecting client.

The LLM Provider generates response tokens. The Stream Service sends tokens back to the Mobile Client through SSE or WebSocket streaming.

Each token has an ordered offset. The service tracks the latest acknowledged offset because this tells the system what the client already received.

The Stream State Store keeps durable stream information. It stores stream identity, request identity, next offset, bounded tokens, status, creation time, and expiry information.

The Bounded Buffer keeps recent tokens for quick replay. Older tokens are removed to avoid unlimited storage growth.

When the mobile connection fails, the server keeps the saved stream state. The client reconnects using the same stream identity and its last acknowledged offset.

The API Gateway / Stream Service validates the reconnect request, checks that the stream exists, and reads the stored state.

The service compares the client offset with the saved offset to decide where recovery should begin.

If the missing tokens are available, the Stream Service replays them and continues streaming new tokens. Token ordering is important because the user should see the response in the correct sequence.

The service resumes from the next expected offset instead of sending duplicate tokens.

Exact resumption is not always possible. The stream may have expired, been canceled, or no longer have the required buffered tokens.

In that case, the service informs the user and restarts generation when possible. The system should not claim exact recovery when it cannot provide it.

The client or server can cancel a stream. The Stream Service stops generation and marks the stream as canceled.

Expiry removes old stream state and releases resources. This prevents storage from growing without limits.

The design improves user experience because short connection failures recover smoothly. The downside is additional storage, cleanup logic, and state management complexity.

This design balances recovery ability and system cost. Durable stream state allows recovery after service restarts, while the bounded buffer keeps only recent tokens for fast replay. The benefit is that users can continue an interrupted AI response instead of starting again. The downside is extra storage and cleanup work. The Stream Service must manage offsets, ordering, expiry, and cancellation correctly. Keeping more history improves recovery but costs more resources. Keeping less history reduces cost but makes long disconnects harder to recover. We accept this trade-off because a practical system needs reliable recovery without unlimited storage.

At a high level, I would keep the streamed conversational AI endpoint stateless for work that only belongs to one request. Authentication, policy checks, routing, cancellation, and temporary buffers do not need durable storage. I would add durable state only for capabilities that need information after the request ends. These include cross-device history, ordered messages, resumable streams, idempotency, and audit records. This keeps the request path fast and easy to scale. The trade-off is that durable state improves continuity and correctness, but adds storage cost and operational complexity.

The question is about deciding what an AI conversation system should remember and what it should forget after a request finishes. We want users to continue conversations, recover from failures, and keep important records when needed. At the same time, we do not want every request to depend on stored data. The goal is to keep the streaming path simple and add memory only when a feature truly needs it. The answer follows the diagram by separating request-scoped work from cross-request durable state.

• Do users need conversation history across multiple devices?
• How long should conversation and audit data be stored?
• Should interrupted streams be resumable?
• What behavior is expected if durable storage is unavailable?

I would first divide the system into request-scoped work and cross-request state. The client sends a request to the streamed AI endpoint. The endpoint handles authentication, policy checks, routing, generation, streaming, and temporary buffers. These operations only exist during the active request, so they should remain stateless.

The benefit is that any server replica can handle a request. The service does not depend on memory from a previous request.

The endpoint verifies the user identity and checks policies before processing the request. Routing selects the correct model or tool path. Generation creates the AI output, and streaming sends tokens back to the client. Cancellation only affects the current stream. Temporary buffers store short-lived request data.

These responsibilities stay stateless because they do not require future requests to know what happened before.

Some features require information after the request ends. Cross-device history needs a conversation store because users may open the same conversation on another device. Ordered messages need stored message order. Resumable streams need checkpoints so interrupted sessions can continue.

Idempotency needs stored request keys and results so repeated requests can avoid duplicate work. Audit and compliance need immutable records for review.

The durable state layer contains conversation stores, ordered message logs, stream checkpoints, idempotency keys, and audit logs. The main request path should not depend on these stores unless the requested capability needs them.

This keeps the normal streaming experience fast while still supporting features that require memory.

I would start with a fully stateless endpoint. Then I would add one durable capability at a time. A minimal durable store can be introduced behind the existing interface. Existing conversations can be migrated gradually, and more state-based features can be enabled later.

This reduces migration risk because every new state dependency can be tested independently.

Durable state introduces new failure cases. If the state store is unavailable, features like history or resume may not work correctly. The system should not claim that data was stored when a write failed.

The design should keep request processing separate from optional state features when possible. The trade-off is better reliability and user experience with additional storage and operational complexity.

This design keeps the AI endpoint simple by separating temporary request work from long-term information. Stateless processing improves scaling because servers do not need previous conversation memory. Durable state is added only for history, ordering, resume support, idempotency, and audits. The benefit is better continuity and correctness. The downside is more storage, more failure cases, and more operational work. A gradual migration is safer because the team can add one state feature at a time. The main trade-off is between simplicity and richer user features. We accept extra complexity only when the user experience or system correctness requires stored information.

At a high level, I would design the video pipeline as a durable asynchronous workflow. The API accepts the video job and creates a job identity. The metadata store tracks the job state, stage, and attempts. The queue, scheduler, and workers process the job step by step. The object store keeps the final outputs. The key reliability decisions are preserving job identity, using idempotent processing, bounding retries, and fencing publication so duplicate work does not create incorrect results. The trade-off is more system complexity, but we get better recovery and correctness.

This question asks how to keep a video processing system reliable when different parts fail. A video job can take a long time, so the user should not wait for one request to finish. We need to accept the job, remember its progress, and complete it safely even when parts become slow or unavailable. The main challenge is avoiding lost jobs and duplicate results. I will explain the design by following the diagram from the client, API, metadata store, queue, scheduler, worker, and object store.

• What is the expected video processing time and traffic level?
• How long should failed jobs and completed job records be retained?
• Do users need live progress updates during processing?

The request first reaches the API. The API accepts the video job, creates a job identity, and returns quickly because processing is asynchronous. The client does not keep an open request while the video is processed. The request identity and idempotency key help prevent duplicate job creation. If the API is slow, we use timeouts and return after the job is safely stored. If the API is unavailable, the client can retry safely.

The metadata store is the source of truth for job state. It stores the job ID, stage, and attempts. Each component can understand what happened and what should happen next. If the metadata store becomes slow, updates may lag, so we monitor latency and keep writes safe. Duplicate updates are handled with idempotent writes using job identity.

The queue stores jobs until workers can process them. This protects the system when many videos arrive together. If the queue becomes slow, backlog grows, so we monitor queue depth and apply backpressure. If messages are delivered more than once, consumers must handle duplicate delivery safely.

The scheduler selects queued jobs and assigns them to workers. It uses leases and heartbeats to know which worker owns the work. If a scheduler response is lost, the job can recover using the stored state and lease information. This avoids losing accepted jobs.

Workers perform the expensive video processing. A worker can become slow because GPU work takes time. We can scale workers and monitor progress. If duplicate workers process the same job, job ID and attempt identity help prevent incorrect updates. Retries are limited so duplicate GPU work stays controlled.

The worker writes completed video outputs to the object store. Fenced publication ensures only the correct attempt publishes the final output. If two workers finish the same job, only the valid result becomes visible. If an upload succeeds but the response is lost, the system verifies the stored result before retrying.

Metrics show queue depth, latency, retries, and worker health. Logs and traces connect request IDs, job IDs, and attempts across the pipeline. Audit history records state changes. Recovery runs use this evidence to understand failures and safely retry work. The trade-off is additional operational complexity, but the system becomes safer for long-running video jobs.

This design chooses reliability over simplicity. A direct synchronous API would be easier, but it would fail for long video jobs because requests can take too long. The metadata store adds more work, but it provides one place to track progress. The queue adds delay, but it protects workers from traffic spikes. Idempotency prevents duplicate jobs and duplicate processing. Bounded retries prevent unlimited GPU usage. Fenced publication prevents an older worker from overwriting the correct result. The downside is more components to operate and monitor. We accept this because video processing needs recovery, visibility, and safe failure handling.