DEV Community

loading...
Cover image for Complex auth - the biggest issue: cache invalidation

Complex auth - the biggest issue: cache invalidation

vaclavhodek
Building SaaS, doing marketing and being too geeky sometimes :-).
Originally published at vaclavhodek.com ・2 min read

For Localazy, we want to introduce a complex solution for managing organizations and teams.

It changes the current simple user-project relation to one of:

  • user-project - it's still allowed as it's the most common case
  • user-organization-project - where both user-organization and project-organization is the N:M relation
  • user-organization-team-project - where user-organization is N:M, user-team is N:M, and project organization is N:M

And all these relations have to be calculated to find the final relation between the user and the project to authorize her to access the service.

Of course, the user authorization has to be processed for every single request and so the only solution is to heavily cache it. It's actually not a big issue to find the final relation and to cache it.

The challenge is to invalidate the cache correctly when any of those N:M relations change. Of course, we don't want to invalidate the cache fully for all touched entities; only what is really necessary.

You have to plan for the invalidation with the same care as for caching from the beginning if you want to do it right! The one of the typical problems is the invalidation of removed relations. Of course, I would expect the soft delete to be in place, but you don't want to go through all soft-deleted items nor you want to store this information, so you can't just have the invalidate() method, you have to pass also information about the operation that led to the invalidation.

And a small tip: Be sure that your cache invalidation works well before running integration/e2e tests :-).


Btw, if you are looking for a way how to localize your web/desktop/mobile app to more languages for free, give Localazy a try and ping me for goodies.

Discussion (0)