[deleted]
Stop Designing Your Web Application for Millions of Users When You Dont Have 100
51–60 of 103 posts
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#52People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…
Scaling databases is easy. But you can really blow performance out of the water if you don't know SQL and use an ORM the naive way. Micro services and things like graphql make it worse. Now you are doing joins in memory in your FF-ing graphql endpoint instead of in the database. A simple cheap database should be able to handle millions of rows and a handful of concurrent users. Meaning that if your users drop by a fe…
Vertical scaling is easy, but horizontal scaling is something that gets complex very fast for SQL databases. More tools, more setup, more things can go wrong and you have to know. If you have no shard like a tenant_id joins easily become something that involves the network.
Managed databases ofc take a lot of that work away from you, but some customers want or need on-premise solutions due to legal requirements or not wanting to get locked into proprietary offerings.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#53This topic lacks nuance. I agree in focusing on building things that people want, as well as iterating and shipping fast. But guess what? Shipping fast without breaking things requires a lot of infrastructure. Tests are infrastructure. CI and CD are infrastructure. Isolated QA environments are infrastructure. Monitoring and observability are infrastructure. Reproducible builds are infrastructure. Dev environments are…
Nowadays there are a lot of tools to setup this infra in a standard way very quickly though - in terms of CI/CD, tests, e2e tests etc.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#54People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…
Scaling databases is easy. But you can really blow performance out of the water if you don't know SQL and use an ORM the naive way. Micro services and things like graphql make it worse. Now you are doing joins in memory in your FF-ing graphql endpoint instead of in the database. A simple cheap database should be able to handle millions of rows and a handful of concurrent users. Meaning that if your users drop by a fe…
>And a big, serious database server can handle insane number of rows and concurrent users. Stackoverflow famously runs on [1] a single database server (plus a second for failover, plus another pair for the rest of the stackexchange network).
[1] Or used to run, this factoid is from many years ago, at its peak popularity.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#55At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…
This is why everyone uses microservices and React. We don't know how these work, but we are netfligs/farcebook level companiez, so we must.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#56This phenomenon needs a term, how about Premature Architecture?
I like it much. It goes well with Premature celebration from startupers. "We raised 100M USD, we made it!", when the company is on the verge of collapse every day and is losing 100M USD per year and has no business model rather than buying something 2 USD and selling it 1 USD.
Well, if that isn't a problem for a future me, I don't know what is.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#57People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…
> The SQL database is probably the hardest part to scale Use an ORM and SQLite, I bet you a beer that you won’t hit the perf ceiling before getting bored of your project.
It really depends on the project. For a CRUD application? Sure. For an application that processes hundreds of events per second, stores them, and makes them wueryable using various filters? Can get tough real quick.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#58At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…
> I had to have a multi-day argument over the precise way to define constants in Perl Couldn't you have used whatever the other person was suggesting even if the change was pointless?
These days, I would, yeah, but this was a long time ago and I was a lot more invested in not letting nonsense go past without a fight.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#59People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…
People also underestimate how financially predictable this setup is - you purchase a VPS or bare metal box on DigitalOcean/Hetzner/OVH for e.g. $50/mo, and that price will likely stay the same for the next 5 years. Try that with any of the cloud providers.
This part is often neglected when running a company, where owners usually hope infra costs will decrease over time or remain proportional to company income. However, I'm still waiting to see that.
Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100
#60Earlier quoted context omitted.
> The SQL database is probably the hardest part to scale Use an ORM and SQLite, I bet you a beer that you won’t hit the perf ceiling before getting bored of your project.
It really depends on the project. For a CRUD application? Sure. For an application that processes hundreds of events per second, stores them, and makes them wueryable using various filters? Can get tough real quick.
That's where SQLite really shines - used it in a massively scaled facial recognition system, with several hundred simultaneous cameras, a very large FR database with over 10K people, each having dozens of face entries, and all the events that generates from live video viewing large public venues. SQLite was never a bottleneck, not at all.