Add L15 slides

lectures/L15.tex

@@ -8,13 +8,11 @@ \section*{It's Not Me, It's You}
 
 Sometimes the limiting factor in our application is something that's not under our control. Whenever your application connects to some other application (whether external or not), we may run up against a rate limit.
 
-A \emph{rate limit} represents the maximum rate at which a requester can make requests of the service---it is exactly what it sounds like.
-
-In other words, how many requests can be submitted in a given unit of time? Requests above the limit are rejected. If we are making HTTP requests, we are supposed to get a response code of 429 for a request rejected due to a rate limit.
+A \emph{rate limit} represents the maximum rate at which a requester can make requests of the service---it is exactly what it sounds like. In other words, how many requests can be submitted in a given unit of time? Requests above the limit are rejected. If we are making HTTP requests, we are supposed to get a response code of 429 for a request rejected due to a rate limit.
 
 Rate limits can be more complicated than just a simple measurement of requests per unit time. For example, there can be multiple thresholds (e.g., A requests per hour or B requests per day), and it may be segmented by request type/responses (e.g., max C requests to change your user data per day, and a max of D requests of any type per day in total). Responses can be more complicated than just rejection also---the service could intentionally delay or deprioritize requests that exceed a threshold---but for our discussion we'll just stick with simple rejection.
 
-Rejected requests can be a huge problem for your application or service. An obvious example here is something like ChatGPT: if you're using that as a service in your application and you run up against the rate limit for that, some aspect of your application (maybe the critical one?) is unavailable or not working as well as expected. I [JZ] have even got a fun story about getting rate limited by a payment processing platform because they would (1) generate an invoice and notify a service via a webhook, (2) the service would then validate the webhook notification is valid by calling the platform, and (3) then get rate limited because the calling application is trying to call the validation endpoint too often in a short period of time. Wait, they're calling us and we're just checking that the call is valid---but unfortunately, they don't care, HTTP 429---Too Many Requests! % PL uh I got a bit confused here. Maybe a funny meme picture would help even in the notes. Clearly there can be one in the slides.
+Rejected requests can be a huge problem for your application or service. An obvious example here is something like ChatGPT: if you're using that as a service in your application and you run up against the rate limit for that, some aspect of your application (maybe the critical one?) is unavailable or not working as well as expected. I [JZ] have even got a fun story about getting rate limited by a payment processing platform because they would (1) generate an invoice and notify a service via a webhook, (2) our service would then validate the webhook notification is valid by calling the platform, and (3) our service would then get rate limit errors saying it is calling the validation endpoint too often in a short period of time. Wait, they're calling us and we're just checking that the call is valid---but unfortunately, they don't care, HTTP 429---Too Many Requests! 
 
 \paragraph{Why is this happening to me?} Rate limits exist because every request has a certain cost associated with it. It takes work, however small or large this might be, to respond to the request. The cost may or may not be measured in a currency---if you are paying for CPU time at a cloud provider, then it literally is measured in monetary units---but it can also be measured in opportunity cost. What do I mean? If the system is busy, responding to one request may mean a delay in responding to other requests. If some of those requests are fraudulent or otherwise invalid, it's taking away time or resources from other, legitimate requests. If the system is overprovisioned, rate limits aren't necessary, but here we're talking about systems that are running closer to the edge.