Timeline for Microservices - sharing data through distributed in-memory cache?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2022 at 7:53 | comment | added | Michał Kosmulski | @RamPrakash Indeed, but note that their CacheManager seems to be a strictly technical service dedicated to maintaining the cache itself. They avoid coupling Billing and Payment services (which have the actual business logic) via the cache directly: CacheManager operates based on events which act as a decoupling layer. So there seems to be no direct dependence of business logic on the cache in any two business services. | |
| Feb 20, 2022 at 19:05 | comment | added | RamPrakash | In this aws design - aws.amazon.com/blogs/architecture/… - cache seems to be shared | |
| Mar 10, 2020 at 7:23 | comment | added | Carmine Ingaldi | yes your example could be applied in a CQRS context, where a command-side microservice is able to invalidate a cache while the read-side microservice hits it | |
| Jul 18, 2018 at 20:41 | comment | added | Lewis Pringle | Agreed. But there is one other fatal problem with this - you often use your memcached or redis server to save CACHED data, but can fetch/compute the underlying data if its not in cache. You need to call through a web-service-layer anyhow to do that computation when the data isn't found in your caching server. | |
| Jul 16, 2018 at 5:38 | vote | accept | TommyF | ||
| Jul 15, 2018 at 19:51 | comment | added | Michał Kosmulski | @TommyF There is a difference between agreeing upon a schema in a REST API and in a database or cache. If you have a REST API, you can change it independently of the underlying database. You can completely change the database your service uses but keep the REST API the same and the client won't even notice. If you access the DB or cache directly, you can't do that and you end up with strong coupling. So the question remains: is the gain in performance big enough to offset the lack of flexibility? In some cases it might but in most it probably isn't. | |
| Jul 15, 2018 at 14:31 | comment | added | TommyF | Great points, thanks for sharing! Just before I completely dismiss the idea: what if we did decouple the data models and used the shared cache only as a shallow copy of the actual business objects? Basically instead of responding to requests through the API, expose the same data that could be requested in the shared cache. We'd still need to agree upon a schema but that's also the case in a standard API request/response and we still get performance and fault tolerance... Still a bad idea? | |
| Jul 15, 2018 at 11:03 | history | answered | Michał Kosmulski | CC BY-SA 4.0 |