It was a lazy lockdown afternoon, and my team had gathered to discuss some architectural decisions for one of our applications. We were building an API to a larger system, which would be accessed via an interface to configure and tweak the components of the system. A component of this API involved acquiring a lock on a certain resource, and releasing the lock after the resource was released. My original proposal involved maintaining an in-memory lock, which would gate access to the resource on that instance of the application. At the time, the amount of traffic coming to that application was quite low, and a single app instance would suffice, at least for the foreseeable future.

It’s Wednesday evening. You’re in the office, almost done pretending to work for the day. You’re thinking about the playlist you’re going to listen to on your commute home. Just then, you see the product manager walking towards you. It’s almost the end of the day, this can’t be good. She tells you, “we’re planning to scale to 2x traffic by Monday. Let’s make sure we can handle it”. You inherited the application being talked about from a departing colleague, and it is virtually unmaintainable. With time in short supply and a refactor not even remotely possible, you get ready to cancel your weekend plans. Just then, an idea hits you. A handful of caches placed at application bottlenecks might just save your weekend. You hack together a patch, and pray it survives Monday. Monday comes along, and your app doesn’t flinch. You wonder if you’re the first one to come up with the phrase “A cache in time saves nine”.