I'm back in Oslo! Writing this the day after recording, it feels like I couldn't be further from Dubai; the temperature starts with a minus, it's snowing and there's not a supercar in sight.
Back on business, this week I'm talking about the challenge of loading breaches and managing costs. A breach load immediately takes us from a very high percentage cache hit ratio on Cloudflare to zero. Consequently, our SQL costs skyrocket as the DB scales to support the load. Approximately 28 hours after loading the two breaches I mention in this week's update, we're still running a DB scale that's 350% larger than once we have a high cache hit ratio, and that directly hits my wallet. We need to work on this more because as I say in the video, I really don't like financial incentives that influence how breaches are handled, such as delaying them and bulking them together to reduce the impact of cache flush events like this. We'll give that more thought, I think there are a few ways to tackle this. For now, here's this week's video and some of the challenges we're facing:
References
- Sponsored by: 1Password Extended Access Management: Secure every sign-in for every app on every device.
- Some people really don't like supercars (although I suspect it's more about not liking to see either the enjoyment others take in them or the success they may have achieved)
- Being online means having constant attacks against your online things (but failed login attempts against my son's and my Microsoft accounts are just that - failed attempts)
- The German electricity provider Tibber had 50k records breached (a little one, but newsworthy enough to have hit the media)
- And the first-ever Senegalese data breach went into HIBP courtesy of Yonéma (not exactly a high cross-over with our usual subscribers, but a breach is still a breach)