Interview Bank
328 questions total; 1 shown with current filters.
CourseAllFrom Frontend Engineer to Agent Engineer in 30 DaysPrompt Engineering From Scratch in 5 DaysMastering Claude: From Conversation to Claude Code in 5 DaysMastering Codex and the OpenAI Agents SDK in 5 DaysMCP in 7 Days: Wire Tools Into Any AgentAgent Skills in 7 Days: Turn Experience Into Reusable CapabilityContext Engineering in 5 DaysRAG in 14 Days: From Retrieval to Trustworthy AnswersBuild an AI Short-Drama Production Pipeline With Agents in 14 Days
Tag
All#stateless1#reliability22#cost15#architecture12#streaming11#security10#observability9#distributed-systems8#idempotency8#multi-agent8#rag7#system-design7
136 more tagsShow fewer tags
#api-design6#operations6#sse6#deployment5#message-bus5#tool-calling5#agent-loop4#behavioral4#error-handling4#evaluation4#framework-design4#mcp4#routing4#concurrency3#context-engineering3#interview-prep3#langgraph3#llm-basics3#model-routing3#orchestration3#prompt-injection3#protocol3#redis-streams3#scalability3#scheduling3#agent-design2#auth2#checkpointing2#communication2#cost-control2#database2#debugging2#interview-process2#latency2#long-term-memory2#memory2#ordering2#prompt-engineering2#rate-limiting2#react2#resume2#retrieval2#sharding2#state-machine2#state-management2#tool-design2#tool-permissions2#trade-offs2#ux2#agent-basics1#agent-quality1#async1#atomicity1#cancellation1#capacity-planning1#career1#chunking1#compression1#configuration1#consistent-hashing1#context1#context-compression1#context-management1#correctness1#customer-support1#data-modeling1#deliberate-practice1#docker1#documentation1#engineering-tradeoffs1#escalation1#event-driven1#fallback1#fan-out1#fencing-token1#forking1#framework-selection1#frontend1#global-market1#hybrid-search1#interrupt-merge1#isolation1#json-parsing1#jwt1#knowledge-organization1#lease1#least-privilege1#llm-as-judge1#loop-guard1#mobile1#multi-tenancy1#nodejs1#performance1#persistence1#pgvector1#portfolio1#prioritization1#proactive-messaging1#product-engineering1#project-storytelling1#prompt1#provider-abstraction1#quiet-hours1#ranking1#recall1#reconnect1#redis1#reflection1#replay1#reporting1#rerank1#retrieval-quality1#retry1#retry-semantics1#rrf1#sampling1#sandboxing1#schema-design1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#service-architecture1#session-management1#split-brain1#star1#storytelling1#structured-output1#system-prompt1#testing1#timezone1#tool-execution1#tools1#tracing1#transport1#vector-database1
From Frontend Engineer to Agent Engineer in 30 Days
D8 Why Split Gateway and Worker; Postgres Table Design (sessions/runs/messages) + Drizzle
What makes a service stateless, what does that mean for horizontal scaling, and are workers stateful?什么是无状态服务?它对水平扩展意味着什么?Worker 算不算有状态?
Common in ChinaCommon overseasIntermediate#stateless#scalabilityHow to reason about it · think before answering
- The trap is reading the word literally. Many candidates say 'it stores nothing', which is wrong — stateless services write to databases all day. The discriminator is whether you can define it precisely.
- One sentence does it: stateless means state does not live in the process handling the request, so any instance can serve any request. Turn it into a self-check: kill a random instance — does any user's data exist only there? Only 'no' is stateless.
- Derive three scaling consequences: a new instance needs no warm-up or data sync and starts serving the moment it joins the load balancer; any instance can be killed at will, which is what makes rolling deploys and spot instances viable; and no sticky sessions are needed, whereas stickiness means rebalancing during a scale-up cuts existing conversations.
- Answer the worker half carefully: it holds execution progress, not user data — which turn it is on, which tools it called, and later a lease. User data always lives in the database. So 'stateful' here means 'holding unfinished work', and the consequence is that you cannot kill it freely: drain first, refuse new work, let the current run finish.
- Expect the follow-up: does an in-memory cache break statelessness? It depends on whether losing it causes wrong behavior. A pure accelerator that only costs latency is fine; the moment a user's session exists only in one machine's memory you are silently relying on stickiness, and the next scale-up will prove it.
分析过程 · 先想清楚再作答
- 这题的陷阱是字面理解。很多人答成「不保存任何数据」,那是错的——无状态服务当然会写数据库。区分度在于你能不能给出准确定义。
- 准确定义只有一句:无状态指的是**状态不留在处理请求的那个进程身上**,因此任意一台实例都能处理任意一个请求。把它翻译成一个自检问题就很好用:随便杀掉一台实例,有没有任何用户的数据只存在于那台机器上?答「没有」才是无状态。
- 再推出水平扩展的三个后果:新实例不需要预热或同步数据,接上负载均衡立刻能干活;任意实例可以随时被杀,滚动发布和抢占式实例才成立;不需要会话粘连,而粘连一旦存在,扩容时的重新分配就会打断老用户的会话。
- Worker 那一问要答得有分寸:它持有的不是用户数据,而是一次执行的进度(跑到第几轮、调了哪些工具、后面还会加上一个租约)。用户数据始终在数据库里。所以说它有状态,指的是「手上有活没交代完」,后果是不能随便杀——必须优雅停机,先拒绝新任务再等手头的跑完。
- 可以预期的追问:内存缓存算不算破坏了无状态?答案是看丢了会不会出错。纯粹用于加速、丢了只是变慢的缓存不破坏无状态;一旦某个用户的会话只存在于某台机器的内存里,你就已经在偷偷依赖粘连了,扩容那天必然出事。
Key points
- Stateless means the state does not live in the request-handling process, so any instance serves any request — not that nothing is stored
- Self-check: kill any instance and ask whether any user's data existed only there
- Three scaling prerequisites: no warm-up, any instance disposable, no sticky sessions
- Workers are stateful in the sense of holding run progress, not user data, so they need graceful drain rather than a hard kill
- A pure accelerator cache is fine; in-memory data that is the only copy is implicit stickiness
答题要点
- 无状态的准确含义是状态不留在处理请求的进程里,任意实例都能处理任意请求,而不是「不存数据」
- 自检方法:随便杀一台实例,是否有用户的数据只存在于那一台上
- 水平扩展的三个前提:新实例无需预热、任意实例可被随时杀掉、不需要会话粘连
- Worker 的有状态指的是持有一次执行的进度而不是用户数据,后果是必须优雅停机而不能随便杀
- 只加速、丢失只降速的缓存不破坏无状态;承载唯一副本的内存数据等于隐式的会话粘连