Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
1–10 of 41 posts
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#2Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#3As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#4This could be the inspiration for a great open source project, and become something that could easily be deployed to a cloud hosting platform. Basically it's the same as firebase, but with some of the react and flux goodness like server side rendering. Or somebody could package this as a product.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#5This could be the inspiration for a great open source project, and become something that could easily be deployed to a cloud hosting platform. Basically it's the same as firebase, but with some of the react and flux goodness like server side rendering. Or somebody could package this as a product.
Where did you see there is server side rendering? Flux and React does not imply server side rendering out of the box.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#6Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#7Great post, but has this design been implemented to effectively handle something close to a million users ( or even 100k and show that no part is overheating) ? As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
Obviously not. Some of his numbers are off by an order of magnitude.
E.g. he claims "10 million messages/sec" for a single redis instance.
In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks
The design is almost comically bad (single source of truth for a "scalable" chat app?!). This is either an attempt at parody or this guy must be suffering from a rather severe case of second system effect...
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#8Great post, but has this design been implemented to effectively handle something close to a million users ( or even 100k and show that no part is overheating) ? As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
but has this design been implemented to effectively handle something close to a million users Obviously not. Some of his numbers are off by an order of magnitude. E.g. he claims "10 million messages/sec" for a single redis instance. In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks The design is almost comically bad (single source of truth for a "scalable" chat app?!)…
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#9Great post, but has this design been implemented to effectively handle something close to a million users ( or even 100k and show that no part is overheating) ? As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
Instead, it's some abstract theory. I believe everyone can dream of any architecture.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#10Great post, but has this design been implemented to effectively handle something close to a million users ( or even 100k and show that no part is overheating) ? As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
but has this design been implemented to effectively handle something close to a million users Obviously not. Some of his numbers are off by an order of magnitude. E.g. he claims "10 million messages/sec" for a single redis instance. In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks The design is almost comically bad (single source of truth for a "scalable" chat app?!)…
Few remarks though:
- it's still way below the number of actions we're talking about here (~100k/s)
- since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering
- I've deployed a similar (but less performant) design for the player of a gaming website, which is in use in production for more than a year, and works like a charm (we're talking ~5-50k users per channel on a daily basis). This is definitely a "second-system" pattern, but I try to avoid the associated pitfalls :)
I'd be genuinely interested by your feedback!