[hire_charts]

Cache-Aside is an Antipattern. It forces you to define your caching logic at the application layer, and suddenly the app must care about--and actually implement--your caching strategy. This is very difficult to scale correctly and is a common source of stale data and race conditions.

Better to treat caching as part of your overall database infrastructure. If caching "hot" data is really important for your app, make sure your data layer supports read-through and write-through caching. Or use the "CQRS" Pattern and read from a different source than your writes (allowing your writes to transparently apply whatever underlying caching strategy you need to support the reads).

The MSDN article on CQRS actually has some good advice on combining it with Materialized Views and handling consistency issues. Worth reading if you're interested in solving your caching problems.

[novaleaf]

i just finished implementing a similar pattern: atomic-cache (cache+eventually consistent modifications) and while it's debatable whether the pattern belongs in your "database" layer or "app" layer, you certainly do need this pattern somewhere.

For me, my orm layer is in my app, and my database is just google datastore. I have ideas for eventually writing a db caching layer as you suggest but it's rather a lot more complexity beyond the "get it working and move on" principle.

[alooPotato]

Are you using something like Objectify with the google datastore?

[novaleaf]

no, just the gcloud-node (npm) module and a home-rolled orm.

objectify looks interesting! but I'm a nodejs user, not java.