This is interesting, I might miss on finding on how you handle cache invalidation when there are some data being updated (not inserted) into the database during heavy reads.
Thanks for the reminder, I maybe missed this out (this piece of software is already two years old). But the idea of course was to update the cache first and afterwards the database.
Will the app serve stale data for a longer period of time until no one is accessing the endpoint?
I do not fully understand you question, but I've created a manager goroutine which cleans up the cache based on the configuration here: github.com/davidkroell/shortcut/bl...
When a particular data it's still being accessed by many users in specific time range, that specific data will still be in the cache, although there's an update data request coming up from another endpoint. Thus new users is getting stale data (old data prior update).
Eventually, after no one is accessing the data for a period of time, the data will be deleted by the cache manager. CMIIW.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the reminder, I maybe missed this out (this piece of software is already two years old). But the idea of course was to update the cache first and afterwards the database.
I do not fully understand you question, but I've created a manager goroutine which cleans up the cache based on the configuration here:
github.com/davidkroell/shortcut/bl...
When a particular data it's still being accessed by many users in specific time range, that specific data will still be in the cache, although there's an update data request coming up from another endpoint. Thus new users is getting stale data (old data prior update).
Eventually, after no one is accessing the data for a period of time, the data will be deleted by the cache manager. CMIIW.