Pinning this comment to emphasize that the proposal employs a write-through caching strategy (this is noted in one of the sticky notes). From 28:30 onwards, I clarify that: - Writes are performed simultaneously to both the Redis cache and the Cassandra database. Both writes must succeed for the data layer service's attempt to persist votes to be considered complete. - Additionally, the database writes occur to Cassandra nodes across multiple data centers, as this is more fault tolerance e.g. what if one data centre is offline
There are some serious issue here WRT single point of failure and consistency.If node fails half way through request i.e written to cache but pending write to DB so system becomes inconsistent overall. What if cache service become unavailable cache usage is not optimal cache is used as DB for read as there's no flexibility to read from DB here. What are your thoughts on this?
Thanks for engaging, see from 28:30 onwards We are employing a write-through caching strategy Writes are done simultaenously to the Redis cache and to the Cassandra DB Furthermore, the writes to the DB are across all data centres, so even if one Data Centre is offline for some reason, we have redundancy There's nothing stopping a direct DB read (This would happen on cache misses in general, although that's not the workflow being proposed) Will pin this as a comment, just in case the diagram is causing you to believe this. Hope this helps!
@@Coditioning Thanks for quick reply. How you ensure that both Writes are done simultaenously and with no failure to the Redis cache and to the Cassandra DB? It's always possible that one succeed and other fail. You try to rollback on your service layer but due to some reason service server failed at that time. Don't we need some sort of distributed transaction for this? There's nothing stopping a direct DB read (This would happen on cache misses in general, although that's not the workflow being proposed) We are using eventual consistency for DB so there is risk into reading from DB as per my understanding.
Pinning this comment to emphasize that the proposal employs a write-through caching strategy (this is noted in one of the sticky notes).
From 28:30 onwards, I clarify that:
- Writes are performed simultaneously to both the Redis cache and the Cassandra database. Both writes must succeed for the data layer service's attempt to persist votes to be considered complete.
- Additionally, the database writes occur to Cassandra nodes across multiple data centers, as this is more fault tolerance e.g. what if one data centre is offline
Good stuff
There are some serious issue here WRT single point of failure and consistency.If node fails half way through request i.e written to cache but pending write to DB so system becomes inconsistent overall. What if cache service become unavailable cache usage is not optimal cache is used as DB for read as there's no flexibility to read from DB here. What are your thoughts on this?
Thanks for engaging, see from 28:30 onwards
We are employing a write-through caching strategy
Writes are done simultaenously to the Redis cache and to the Cassandra DB
Furthermore, the writes to the DB are across all data centres, so even if one Data Centre is offline for some reason, we have redundancy
There's nothing stopping a direct DB read (This would happen on cache misses in general, although that's not the workflow being proposed)
Will pin this as a comment, just in case the diagram is causing you to believe this. Hope this helps!
@@Coditioning Thanks for quick reply. How you ensure that both Writes are done simultaenously and with no failure to the Redis cache and to the Cassandra DB? It's always possible that one succeed and other fail. You try to rollback on your service layer but due to some reason service server failed at that time. Don't we need some sort of distributed transaction for this?
There's nothing stopping a direct DB read (This would happen on cache misses in general, although that's not the workflow being proposed) We are using eventual consistency for DB so there is risk into reading from DB as per my understanding.