Learn how to design large-scale systems
31–40 of 199 posts
Re: Learn how to design large-scale systems
#32Earlier quoted context omitted.
What's the distinction between a database access layer and read/write apis? Is that a semantic distinction or do they accomplish different things?
from my understanding you get the ability to put the DAL into a "pause" mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime. It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage
> It also gives you a way of controlling what queries are used by the API servers preventing a developer from doing silly things and creating a production outage
Also called database roles. Do your DALs have full database admin credentials?!
> mode where it queues all the api requests allowing you do to updates / upgrades to the database with no downtime.
This is just a bad idea. Better idea: unless you are rewriting your entire schema from scratch, you should be able to use database views, database triggers, extra/duplicated columns and tables as you make schema swaps.
Is that a performance burden? Yes, though it is temporary and a lot less of a burden than a whole 'nother layer of indirection. Does this also allow the really nice feature of not stopping your entire system to change schemas? Yes. How about allowing testing new schemas in production piecemeal? Yes.
Re: Learn how to design large-scale systems
#33Note that HN, a top-1000 site in the US, runs on a single box via a single racket process. "The key to performance is elegance, not battalions of special cases."
Re: Learn how to design large-scale systems
#34Re: Learn how to design large-scale systems
#35Note that HN, a top-1000 site in the US, runs on a single box via a single racket process. "The key to performance is elegance, not battalions of special cases."
HN has the luxury of being able to make few high level changes over years, though. It might be tougher to maintain that single box elegance and performance if they were adding new features every month or two (which is much more applicable to the rest of us).
Why should adding features make an app crumble on a single server?
I think the point is that good software is able to serve a lot of users on a single server.
A great example imho is Blender. Features are added constantly but because the software is modular it doesn't have any impact on the overall performance.
Today the problem is that adding features means: adding the latest and greatest lib while having absolutely no idea about the inner workings.
Yes it takes time to write your own libs. But when performance is an issue you will either have to write your own lib or take one that is good and tested.
Re: Learn how to design large-scale systems
#36Re: Learn how to design large-scale systems
#37One well designed fast app server can serve 1000 requests per second per processor core, and you might have 50 processor cores in a 2U rack, for 50,000 requests per second. For database access, you now have fast NVMe disks that can push 2 million IOPS to serve those 50,000 accesses.
50,000 requests per second is good enough for a million concurrent users, maybe 10-50 million users per day.
If you have 50 million users per day, then you're already among the largest websites in the world. Do you really need this sort of architecture for your startup system?
If anything, you'd probably need a more distributed system that reduces network latencies around the world, instead of a single scale-out system.
Re: Learn how to design large-scale systems
#38Note that HN, a top-1000 site in the US, runs on a single box via a single racket process. "The key to performance is elegance, not battalions of special cases."
HN has the luxury of being able to make few high level changes over years, though. It might be tougher to maintain that single box elegance and performance if they were adding new features every month or two (which is much more applicable to the rest of us).
Most of the work is server side, e.g. voting ring detection. We only notice indirectly, when the quality of the site goes up.
Re: Learn how to design large-scale systems
#39Re: Learn how to design large-scale systems
#40Note that HN, a top-1000 site in the US, runs on a single box via a single racket process. "The key to performance is elegance, not battalions of special cases."