Loop/Architecture/Redis: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 36: Line 36:
First of all we need to think about sharding never the less 60GB is a too close constrain as we keep adding data that can stay for longer than before inside the database (rooms-url, sessionToken, call-urls)
First of all we need to think about sharding never the less 60GB is a too close constrain as we keep adding data that can stay for longer than before inside the database (rooms-url, sessionToken, call-urls)


We need sharding to make sure we will continue to scale up our cluster even if we need to store more than 60GB of data in it.
We need sharding to make sure we will continue to scale up our cluster even if we need to store more than 237GB of data in it.


My plan is to build a cluster with 10 small elasticache redis instance (and there read only replicas) that we will be able to scale up using TwemProxy.
My plan is to build a cluster with 5 small elasticache redis instance (and there read only replicas) that we will be able to scale up using TwemProxy.


TwemProxy will be responsible for sharding the keys.
TwemProxy will be responsible for sharding the keys.
68

edits