Hacker News new | ask | show | jobs
by dano 2849 days ago
This. Often I've had discussions about APIs that take 100ms or more to return a result where the person writing the API and even the product manager do not understand that this response time is likely too long. Going back to the 1960's and the PLATO system, engineers recognized that humans need a response in 500ms or less whether visual, audio, or haptic, to inform them that the system received the input. Therefore, to give a user that same 500ms response time today across the Internet, not just across the room to the mainframe, requires understand the entire latency chain. One approach is to consider that any interaction has a 500ms budget which cannot be exceeded and then start subtracting out the various latency components. Round trip time across the USA, 150ms. DNS, Connect, HTTPS negotiation, TCP setup, etc.. 25ms. Suddenly your down to to 300ms of remaining budget. Lets assume that 5 service API calls need to be made internally to provide the response, 300 / 5 = 60ms avg budget per API call. I'm going to tell you that with today's CPU/RAM/SSD speeds, 60ms is a huge amount of computing time for a reasonable request.

tl;dr, remember the 500ms overall budget for the humans at the end of the pipeline. No one anywhere said I want my response time slower.