Latency is the time between asking for something and getting it back — and understanding it is the first step to making your applications feel fast and responsive.
You open EngineerPrep and click 'Start Mock Interview.' The spinner spins. One second. Three seconds. Five seconds. You're not sure if the app is working. That uncomfortable pause is latency in action. Now imagine you're the engineer who built that feature. Your code works — the interview does start eventually. But your users are already frustrated. Your manager is asking why it feels slow. And you're not sure what to measure or where to look. Most beginners assume latency is just about slow networks or underpowered servers. That's a natural first guess. But latency is a more precise idea than that — and once you understand what it actually is, you'll know exactly where to look when things feel slow. So: what exactly is latency, and why does it show up in so many different places?
Latency is the time between sending a request and receiving a response. That's it. Think of it like ordering coffee at a café. The moment you say 'one flat white, please' is the request. The moment the barista hands it to you is the response. The time in between — thirty seconds, three minutes, whatever it is — is your latency. Notice: latency has nothing to do with how much coffee is being made, or how many customers are in line. It's purely about your wait from request to response. In software, latency is measured in milliseconds (ms) — thousandths of a second. A response in 50ms feels instant. A response in 3000ms (three full seconds) feels noticeably slow to most users. Every time EngineerPrep does something — fetches a question, calls the AI tutor, generates a lesson — there is a latency number attached to that action. Some are small. Some are not.…
Picture a timeline — a straight horizontal line representing time, moving left to right. Step 1 — The request leaves the browser. A learner clicks 'Find a Question' in EngineerPrep. At the far left of the timeline, a small dot appears. Label it: t=0ms . This is the moment the request is sent. Step 2 — The request travels across the network. The request has to travel from the learner's laptop to EngineerPrep's server on AWS. Draw a small arrow moving right along the timeline. A few milliseconds tick by. Label this gap: network travel time . The server hasn't done any work yet — this time is pure travel. Step 3 — The server receives the request and starts working. The server receives the message. Now the real work begins: Spring Boot processes the HTTP request, a database query runs against PostgreSQL to find matching questions using pgvector, and a result is assembled.…