68
edits
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 | 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 | 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. | ||