Yes, that's right, it can be on a case-by-case basis, and something that was offered to us at DAZN at the time, but we didn't want to be in a situation that the viability of our solution depends on constantly rengotiating a "soft hard limit" with AWS, hence our rule about services on the critical path. You can't raise the burst capacity limit via the service quotas console, I guess because they don't want to make it too easy as most people shouldn't come close to the limit. And in my opinion, if you do need to raise the burst capacity limit, then it's an argument for you to reconsider if Lambda is the right compute platform for that workload.
This is a preview lesson from my cohort-based workshop, "Production-Ready Serverless". If you liked this, then please check out the full curriculum at productionreadyserverless.com. You can get 15% OFF with the code "CZcams15" during checkout. Hope to see you there!
Not sure what you mean. Who's implementing the webhook? The cache service or your application? You can already trigger cache invalidation in most cases - CloudFront supports it, as do most CDNs. And if you're using an application cache (like Momento) then it's just a case of your application deleting the cached response when you want to. Some managed caching layers don't support cache invalidation, or only supports cache invalidation partially. e.g. the API Gateway cache lets you flush the whole cache, not individual items.
ok, no probs! I want to be clear though. Yes, you can invalidate individual cache items when some event happening in your system in most cases. But there is still eventual consistency at play because the action of updating the source of truth and invalidating the caching is not atomic. And when you have an edge cache, with your data cached in a distributed network of machines across vast geographic areas, cache invalidation can take time. On CloudFront, it takes up to a few minutes I believe. So that leaves a lot of room for race conditions to happen. So, not every application and every piece of data is cacheable, but a good tip is to always be on the look out for opportunities to apply caching.
bravo Yan :) !!
Exceptional content as always!
Caching is such an important topic that many times "we" don't get it right 👏 😄
haha, thanks man, glad you enjoyed it!
The lambda burst limit is a "hard quota", but it can actually be raised for eligible workloads via business support, etc.
Yes, that's right, it can be on a case-by-case basis, and something that was offered to us at DAZN at the time, but we didn't want to be in a situation that the viability of our solution depends on constantly rengotiating a "soft hard limit" with AWS, hence our rule about services on the critical path.
You can't raise the burst capacity limit via the service quotas console, I guess because they don't want to make it too easy as most people shouldn't come close to the limit. And in my opinion, if you do need to raise the burst capacity limit, then it's an argument for you to reconsider if Lambda is the right compute platform for that workload.
This is a preview lesson from my cohort-based workshop, "Production-Ready Serverless". If you liked this, then please check out the full curriculum at productionreadyserverless.com.
You can get 15% OFF with the code "CZcams15" during checkout. Hope to see you there!
Do you think we should implement service side webhooks to cache layer just like payment gateway to solve cache validation to significant extent?
Not sure what you mean. Who's implementing the webhook? The cache service or your application?
You can already trigger cache invalidation in most cases - CloudFront supports it, as do most CDNs. And if you're using an application cache (like Momento) then it's just a case of your application deleting the cached response when you want to.
Some managed caching layers don't support cache invalidation, or only supports cache invalidation partially. e.g. the API Gateway cache lets you flush the whole cache, not individual items.
@@theburningmonk Yeah, exactly what you described.
Thanks for the detailed outlook
ok, no probs!
I want to be clear though. Yes, you can invalidate individual cache items when some event happening in your system in most cases. But there is still eventual consistency at play because the action of updating the source of truth and invalidating the caching is not atomic.
And when you have an edge cache, with your data cached in a distributed network of machines across vast geographic areas, cache invalidation can take time. On CloudFront, it takes up to a few minutes I believe. So that leaves a lot of room for race conditions to happen.
So, not every application and every piece of data is cacheable, but a good tip is to always be on the look out for opportunities to apply caching.
@@theburningmonk gotcha 👍🏻