Tales from a Developer

A few years back a now ex-coworker implemented a feature. Nothing wrong with that. Besides, it had a caching problem I needed to fix.

Let’s dig down the rabbit hole.

The application I’m working on has a custom model handler for the backend requests we do. When I started working on that product, I implemented a caching layer on it, as we needed one. We have some heavy data loading to do and keeping things in the local storage of the browser keeps things fast.

Sometime later my coworker implemented a new feature. I’m not sure if he forgot about the base caching layer or if he thought it might not suffice. Anyway, he implemented a small in-memory cache at the location where the new feature was used. A little bit more than needed, but in our normal testing process, nothing that would be found.

Later we implemented cache invalidators. For example, when the user changes its language, certain caches need to be cleared. We now got a customer who doesn’t change the language but changes a core part of our application regularly, for now, let’s call it departure. Obviously there can be multiple departures and obviously you can switch between them.

Caches need to be invalidated when switching department. Again, nothing special and switching departments is functionality we had from the first moment on. The problem lies in the small in-memory cache. That one doesn’t get invalidated or cleared.

I removed the memory cache and voila, it didn’t work. Now the Framework we are using isn’t triggering a rerender when we change the department. Great. Back to the drawing board.