Architecture, Data, and Request Flow

An AI plane adds powerful components to a design, but every one of them must sit beside the traditional core, never replace it.

The middle of a design answer is not a box diagram; it is proof that the boxes interact. Draw the request path, choose a store per access pattern, give each service an owner, and then trace one real request through all of it, as set up in The Twelve-Part Design Framework.

Objectives:

• draw the traditional request path and say the one detail per block that shows judgement;
• add the AI-specific components and explain where each sits and what it risks;
• decide SQL versus NoSQL with one question, and trace a request end to end.

Part 5 is the major blocks and the path a request takes: users, CDN, load balancer, API gateway, application services, databases, cache, message queue and monitoring. Naming the blocks earns little. Each block earns credit only with the detail that shows judgement.

AI systems add components the traditional path lacks. Treat each as a dependency with a specific risk, because that risk is what an interviewer probes.

The integrated picture shows where these sit. The AI plane hangs off the same gateway as the traditional services and calls back into them through the tool layer.

Read six claims off the picture. Two planes share one front door: chat goes to the orchestrator and REST goes straight to services, so a model outage never takes down booking. The tool layer is the boundary. Everything the agent does to the real world passes through typed, permission-checked tool calls into existing services, and the LLM never touches a database directly.

Retrieval is a side path, not an extra hop, so it can be skipped when a task does not need it. A semantic cache hit returns with no model call, no retrieval and no tool execution, so tune its threshold conservatively. Guardrails bracket the model: input checks run before it and output checks validate structure and grounding after it, and both fail closed on transactional requests. Finally, the data and async planes stay shared. The AI plane adds to the traditional architecture; it replaces none of it.

Part 6 picks a store per access pattern and says what is stored, where and for how long.

One question decides SQL versus NoSQL. Does this write need to be correct together with another write, or this read together with another read? Booking a flight decrements inventory, inserts the booking and charges the payment. If the charge fails, the decrement must roll back, or a seat is sold that nobody paid for. That is a transaction, which is what SQL guarantees, and bookings also need joins across users and payments.

A hotel catalogue is the opposite. Reading one listing never locks or joins against another. Different hotels also have genuinely different shapes, such as pet_friendly versus conference_rooms, and rigid columns would mean a table of NULLs. The same logic puts sessions in Redis or NoSQL, being independent, high-volume and ephemeral. Bookings and payments go in SQL, being interdependent, transactional and permanent.

Name the data models too. Customer is privacy-sensitive, so plan for export and deletion. Booking is a state machine with an immutable event history, not a mutable row. Flight data is external and cache-heavy with short TTLs. Hotel data changes slowly and suits a search index plus a CDN. Payment needs the strictest consistency and audit, and stores tokens, never card data.

Then state four storage decisions. Hot versus cold tiering is often the largest cost lever. The partitioning key matters because a bad one creates hotspots that need a migration to fix. Replication mode trades safety for speed: synchronous is safer and slower, asynchronous is faster and risks recent writes. Backups need a defined RPO and RTO plus restore drills, because a backup never restored is a hypothesis.

Warning: the LLM never touches a database directly. Every action the agent takes must go through the tool layer, where authorisation, timeouts and audit are enforced. A model with a direct connection has no choke point, so none of those controls can apply.

Part 7 zooms into each service: what it is responsible for, what it exposes and what data it owns.

The authentication service handles login with credentials or OIDC, and rate limiting and lockout live there. It issues short-lived JWT access tokens with longer refresh tokens, and rotation and revocation need a plan. Step-up MFA before payment or cancellation is a good detail to volunteer. Session validation happens at the gateway, fast and cacheable.

The booking service reserves seats atomically with an idempotency key, so retries never double-book. Reservations expire if payment does not complete. Payments run as a saga with compensating actions, because the provider is external. Cancellation is idempotent and auditable, since partial failures here are customer-visible.

The AI agent classifies intent with a confidence score, and low confidence produces a clarifying question, not a guess. It plans with a step and token cap. It invokes tools with validated arguments and explicit permission checks on every write-capable tool. Its memory retrieval is scoped strictly per user and selective rather than a dump.

Part 8 is where interviewers check that the pieces actually interact. Trace one request: user, gateway, authentication, supervisor agent, semantic cache, travel agent, flight API, hotel API, booking service, LLM and response.

A candidate draws one NoSQL store for the whole travel assistant, for scale. Apply the deciding question to bookings. A booking must commit together with an inventory decrement and a payment charge, or a seat sells unpaid. That is a multi-record transaction NoSQL gives up, so bookings move to SQL.

Apply it to the catalogue. No hotel read depends on another, and the attributes differ per property. Forcing them into SQL columns creates a table of NULLs, so the catalogue stays in NoSQL behind a search index and CDN. Sessions follow the catalogue into Redis.

The single store became three, each justified by one sentence. That is what part 6 is for: a store per access pattern, defended by the access pattern, not by fashion.

• Name each block on the request path with the one detail that shows judgement.
• The AI plane sits beside the service plane, reaches it only through a typed tool layer, and brings a specific risk per component.
• SQL versus NoSQL is decided by whether operations must be correct together; tiering, partitioning, replication and backups are stated decisions.
• Each service has explicit responsibilities, interfaces and owned data.
• One traced request proves the components interact and shows where trace IDs, budgets and caches act.

1. Why does a semantic cache false hit matter more than a normal cache miss? A miss is only slower. A false hit returns an answer to a different question, which is a wrong answer. Tune the threshold conservatively.

2. Why route chat and REST traffic differently at the gateway? Chat goes to the orchestrator and REST goes straight to services. A model outage then cannot take down booking.

3. Where should a sessions table and a payments table live, and why? Sessions in Redis or NoSQL: independent, high-volume and ephemeral. Payments in SQL: transactional, audited and correct together with bookings.