 Okay, what they asked about apart from tracing, is there any other way to pinpoint latency? So obviously tracing essentially helps you tie up the performance across a distributed system. The latency, in the paradigm of observability, you have a lot of metrics also coming in, right, where you can definitely emit metrics and look at the overall service level. But when you're talking about tracing the latency at a single request level, obviously tracing is the right way. Second question, Lex is asking certain system majority of users may face P95, P99 affecting overall user experience at an individual level. You use any of the metrics which try to marry US less latency. Lex also asked, do you use any metrics which try to marry US less latency? Okay. So there are two parts, right? When you're talking about a server, server response times, latency is the primary criteria that we are talking about over here. From a user experience perspective, you know, if you're building a mobile app or a mobile site, you know, there are other things that come into the picture. They can be your page loading time, so they could be your page rendering times as well, right? So I'm sure if there's any front-end engineer in the audience, right, they would tell you that how much energy and effort goes in terms of optimizing the page rendering and the page loading time, right? So that is another measure which is important for optimizing for user experience and the server-side latency is definitely add a lot to the page loading times that you have, right? However, the page loading time is not something that is in the context of the paper and context of the discussion that we have. So we are focusing primarily on the server-side response latencies that we have. Yes, it has a similar question. Asking the network latencies like customer using 3G, etc., does it stay in consideration? I think... Sometimes variability is due to network issues like customer being in 3G, at least in the context of this discussion and paper that is not relevant because what we are talking about is the latency which is within the data center or within the server-side context, right? So when you're talking about variability using because of 3G, you know, we are talking about the latency between the client device and the server endpoints, right? What this paper is arguing about is the techniques which you apply on the... What happens once the request has entered your server's domain, okay? So, however, that point is valid. That variability can come because of 3G network, but the techniques that you're talking about in this paper will not be applicable over here because this latency is just outside the domain of the server or your application server-side. Great. Any other questions, Anu or Salam, move forward. Yeah, I have a question. So running all background jobs at the same time looks kind of counterintuitive because especially given experience of setting up ground jobs in Unix where you make sure that you don't set up same minute and make sure you put a random minute every time. So that somehow sounds counterintuitive, really. Right. So... No, absolutely. I think when I read that statement for the first time, even that came about as a very counterintuitive to me, right? However, what we are talking about here is that, you know, that what we need to be aware of is that, you know, at any software system, right? Unless we are talking about Google scale, which is operating across the globe 24-7, right? Where it is possible that the request distribution or the traffic throughput that you see on the system can be uniform. However, you know, in my experience, what I've seen is that, you know, there are certain time zones or there are, I mean, there are certain times in a day when any part of your infra would be seeing a less number of traffic, right? So basically the number of requests or the throughput that your system has in that window is going to be much lower than the throughput that you have during other hours, right? So what we are trying to do here is that, you know, you're trying to schedule your background jobs to run at a time when the system is operating at a much lower throughput than its peak number, right? The reason being, if a disruption happens at a time and there is a lot lower throughput, right? The overall, the impact of the, of the disruption on the percentile latency would be on a much lesser number of users than what it would be if you are running it at a much, at a time when your system is running at peak capacity, right? So just to give you some example of, from the experience that I have had at Capillaria in Mobi, right? So, yeah, in Mobi, we had around five, four, four global deployments, right? Those deployments were designed for the different time zones of globally, right? So we had systems which used to hit their peak at 3 a.m. in the morning. Well, at the same time, we had a deployment in Hong Kong, which was kind of running at the, at that time, it was in the night, right? So the system was operating at probably one-fifth or one-sixth of the capacity, right? So if you kind of run my crown jobs or background jobs during that time, the number of records which get impacted by the disruption is much lower. And then what it would be if I run the crown job even on a single server when I'm operating at full capacity, right? So that's how it kind of, these numbers play out, essentially. Yeah, but I understand that. But from the paper, what it sounds like is, let's say you have two rate-up servers used to handle the requests, do I take the backup of both of them around the same time, or do I kind of have to take them at different times? Oh, and again, so I mean, it might also depend on your, your application context, right? So one thing to kind of be very, to be kind of cognizant of in the paper is that we are talking about systems which are operating at a much larger scale, right? So I'm not talking about two servers. I'm talking about probably 100 or 2000 of servers, right? So some of these, some of these propositions may not make a logical sense, or they may not be very useful at a smaller scale, right? Because you're talking about at a scale where your universal scalability law and your law of large numbers start becoming applicable, essentially. I think we have one more question, how do API design choices like REST and GraphQL affect the variability of latency from a server-side perspective? See, I think in the context of this discussion, you know, the techniques and the, then the variabilities that we are talking about, they are agnostic to your software or your application level architecture, essentially, right? So the techniques that we are talking about are, are kind of cutting across all of your architecture, whether it is a REST design or it is a GraphQL design, right? Because you're talking about something which is at a slightly lower level, right? We are talking about how your, your web servers or your TCP servers process request, right? So we are not talking about application level architecture, we are talking about one layer, one layer slightly lower than that.