The rule underneath the web
Take those 400 milliseconds apart, starting with the rule underneath all of it. The client asks, the server answers.
Your browser sends a request, a server sends a response, and then the connection goes quiet. That server has no way to tap your browser on the shoulder afterwards. Every time you meet WebSockets or server-sent events in a design, they exist to work around exactly this.
The path one request takes
Follow the path a request takes. Your browser turns a hostname into an address using DNS, the system that maps names like example.com to the numeric addresses machines actually use. It opens a connection and sends the request to whatever answered, usually a load balancer rather than your application. The balancer picks one of many identical servers, that server does the real work, usually a database query or two, and the response retraces the whole route.
Every hop is somewhere that can be measured, cached, or broken, because that habit is worth more than the diagram. The balancer is often where encryption terminates. The application server is where your code and your bugs live. The database is usually where the time goes. When a page is slow you walk the same path with a stopwatch and find 2 milliseconds in the balancer, 8 in your code, and 90 in one bad query.
You will be scored on this narration, because interviewers weight it heavily and they are right to. Open with the path itself: DNS, then the load balancer, then one of several identical application servers, then the database. You have drawn half the diagram before touching the whiteboard. Open with microservices trivia and you will be asked where the connection actually lands, which is the question that separates memorised answers from understood ones.
Worked example
Ananya opens her banking app and taps her balance. The app resolves api.examplebank.com, which DNS answers with the IP of an AWS load balancer. The balancer holds around 40 app servers behind it and forwards her request to server 23. That server checks her session token, runs one query against Postgres, the relational database behind the service (11 ms), formats a small JSON response, the text format APIs answer in, of about 2 KB, and returns it. Total time from tap to rendered number: roughly 120 ms, of which 60 ms was network transit between her phone in Pune and the region in Mumbai. Nothing about server 23 mattered; server 7 would have produced the identical answer, which is exactly why the balancer is free to pick any of them.