Your ADK agent runs on several replicas — which session, memory and artifact services do you pick?

## Three stores, three decisions ADK's `Runner` is constructed with a session service, and optionally a memory service and an artifact service. Nothing forces them to be equally durable, and treating them as one "persistence setting" is the first mistake. Sessions hold conversation threads and small state; memory holds searchable material from past sessions; artifacts hold bytes. They have different sizes, different access patterns and different deletion obligations. ## What multi-replica actually breaks The in-memory implementations are per-process dictionaries. With one process they behave like a real backend, which is why they survive so far into a project. Put two replicas behind a load balancer and the failure is intermittent rather than obvious: a conversation works while sticky routing holds and forgets everything when a request lands elsewhere or a pod is rescheduled. The same applies to artifacts (a file uploaded on replica A is missing on B) and to memory (ingested sessions are visible only to the process that ingested them). So the baseline is: **any horizontally scaled deployment needs external storage for every store it actually uses.** "Actually uses" matters — an agent with no artifacts does not need an artifact service at all, and adding one you do not need is a store to secure and delete from for no benefit. ## Self-operated versus managed `DatabaseSessionService` with a SQLAlchemy URL gives you a store you can inspect, back up, and keep inside your own compliance boundary. In exchange you own migrations of ADK's schema across framework upgrades, connection pooling under concurrency, and growth: every turn appends events, so a chatty agent's session table grows monotonically until you define a retention policy. Nobody does that for you. `VertexAiSessionService` and `VertexAiMemoryBankService` remove that operational load and, for memory, give real semantic recall rather than the keyword stub. The cost is coupling: your conversational data lives in a specific vendor's service under its terms and regions, and portability away from it becomes a project rather than a config change. That is a genuine architectural commitment, not an implementation detail, and it should be made explicitly. A common middle position is a self-operated Postgres for sessions — the store most likely to hold regulated content and most likely to be queried in incident review — with managed memory, where the semantic capability is the point and the data is derived rather than authoritative. ## Sizing and hygiene **Keep state small.** Everything persisted in session state is reloaded with the session on every subsequent turn. Ids, flags and short preferences belong there; documents and payloads do not. Use `temp:` for intermediates that must never be written and artifacts for bytes, storing only the filename in state. **Bound history.** Sessions are append-only. Decide when a thread ends and a new one begins, and what happens to old ones: archived, ingested into memory, deleted. "Forever" is a decision too, and usually the wrong one. **Scope carefully.** Session and memory access are keyed by `app_name` and `user_id`. Those arguments are effectively an authorization boundary; deriving them from anything a client can influence is how one user's history reaches another. Multi-tenant deployments should also remember that `app:`-prefixed state is shared across everyone under that app name. **Plan deletion once, across three stores.** A user-deletion request has to reach sessions, memory and artifacts, plus any of your own tables holding ids. Designing that after launch is much harder than designing it before. ## Failure behaviour Externalising storage introduces a new failure mode: the store can be down. Decide up front what the agent does when the session service is unavailable — fail the request loudly, or serve a degraded stateless turn — and make sure a partial turn leaves coherent history, since events are appended as they are produced rather than in one commit. Also consider concurrency: two workers driving one session both append, and last-delta-wins on a contested state key, so either serialise per session or keep a session to a single writer. ## The answer an interviewer is listening for Not a service name, but the reasoning: which stores this agent genuinely uses, what each must survive, who operates it, how big it gets, how it is scoped, and how it is deleted. Naming `DatabaseSessionService` is the easy half; owning retention, tenancy and the vendor commitment is the half that distinguishes a lead.