71–80 of 96 posts
Earlier quoted context omitted.
> Just up the RAM and CPU up to TB levels not sure what CPU at TB levels means but hope your wallet scales better vertically
They are definitely not on the cloud.
It's not cheap at roughly $200/hr but already if you have this type of traffic then you are generating revenues (hopefully) at much greater amounts.
Postgres can be scaled vertically like Stackoverflow did. With cache on edge for popular reads if you absolutely must (but you most likely dont). No need to microservice or sync read replicas even (unless you are making a game). No load balancers. Just up the RAM and CPU up to TB levels for heavy real world apps (99% of you wont ever run into this issue) Seriously its so create scalable backend services with postgres…
Our backend at work does use a read replica purely for websockets. I always wondered if it was overkill, I’m not a backend developer, though.
making read replicas function also as writes is needed for such cases but already when you have more than one place to write you run into edge cases and complexities in debugging
Earlier quoted context omitted.
Our backend at work does use a read replica purely for websockets. I always wondered if it was overkill, I’m not a backend developer, though.
not sure what you are building but i hope that was for a real time multiplayer game otherwise doesn't make sense to have bi-directional communication when you only need reads making read replicas function also as writes is needed for such cases but already when you have more than one place to write you run into edge cases and complexities in debugging
I don't understand why you wouldn't just use Elixir/Phoenix if you need to scale?
Scaling a non-scalabe by default framework that should have been few services written in a performance first language at a billion+ USD company. I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably R…
"For millions of users the CPU cost difference probably justifies the rewrite cost." This is only true if you have expensive computations done in Ruby or Python or similar, which is very rarely the case.
Earlier quoted context omitted.
Yes, scaling vertically is much easier than scaling horizontally and dealing with replicas, caching, etc. But that certainly has limits and shouldn’t be taken as gospel, and is also way more expensive when you’re starting to deal with terabytes of RAM. I also find it very difficult to trust your advice when you’re telling folks to stick Postgres on a VPS - for almost any real organization using a managed database wil…
looking at hetzner benchmarks i would say VPS are quite enough to handle Postgres for Alexa Top 1000. When you approach under top 100, you will need more RAM than what is offered. But my point is you won't ever hit this type of traffic. You don't even need Kafka to handle streams of logs from a fleet of generators from the wild. Postgres just works. In general, the problem with modern backend architectural thinking i…
Earlier quoted context omitted.
looking at hetzner benchmarks i would say VPS are quite enough to handle Postgres for Alexa Top 1000. When you approach under top 100, you will need more RAM than what is offered. But my point is you won't ever hit this type of traffic. You don't even need Kafka to handle streams of logs from a fleet of generators from the wild. Postgres just works. In general, the problem with modern backend architectural thinking i…
I work at a startup that is less than 1 year old and we have indices that are in the hundreds of gigabytes. It is not as uncommon as you think. Scaling vertically is extremely expensive, especially if one doesn’t take your (misguided) suggestion to run Postgres on a VPS rather than using a managed solution like most do.
Postgres can be scaled vertically like Stackoverflow did. With cache on edge for popular reads if you absolutely must (but you most likely dont). No need to microservice or sync read replicas even (unless you are making a game). No load balancers. Just up the RAM and CPU up to TB levels for heavy real world apps (99% of you wont ever run into this issue) Seriously its so create scalable backend services with postgres…
Earlier quoted context omitted.
"without blowing $250,000/month on their AWS bill". The point is that you don't need AWS for this! You can use Docker to configure much , much cheaper/faster physical servers from Hetzner or similar with super-simple automated failover, and you absolutely don't need an expensive dedicated OPS team for that for this kind of simple deployments, as I read so often here on HN. You might get surprised as how far you can g…
You ain’t replacing 250k/mo worth of ec2 with a single hetzner server so your “super-simple failover” option goes out the window. Baremetal is not that much faster if you’re running ruby on it, dont fall for the marketing.
By the way, I was running my startup on 17 physical machines on Hetzner, so I'm not talking from marketing but from experience.
Earlier quoted context omitted.
We use 5 ec2 instances to serve around 32 million requests per day on PHP, all under 100ms. It is not the language.
Sounds impressive until you realize that there’s 86400 seconds in a day and so even if majority of those happen during business hours thats still firmly under 200 qps per server. On modern hw that’s very small. Also what instance size?