Whatever your service is, usually the database is the bottleneck.
The database limits the latency, scaling and availability.
Of course, how much, depends on the service. Particularly, how much concurrent writing is happening, and do you need to update this state globally, in real-time as result of this writing. Also, is local caching happening and do you need to invalidate the cache as well as a result of this writing.
The most of the relevant problems disappear, if you can just replicate most of the data without worrying that someone is updating it, and you also don't have cache invalidation issues. No race conditions. No real-time replication issues.
> Whatever your service is, usually the database is the bottleneck. The database limits the latency, scaling and availability.
Database-driven traffic is still a tiny percentage of internet traffic. It's harder to tell these days with encryption but on any given page-load on any project I've worked on, most of the traffic is in assets, not application data.
Now, latency might be a different issue, but it seems ridiculous to me to consider "downloading a file" to be a niche concern—it's just that most people offload that concern to other people.
> It's harder to tell these days with encryption but on any given page-load on any project I've worked on, most of the traffic is in assets, not application data.
Yet you have to design the whole infrastructure to note that tiny margin to work flawlessly, because otherwise the service usually is not driving its purpose.
Read-only assets are the easy part, which was my original claim.
> Read-only assets are the easy part, which was my original claim.
I don't think this is true at all given the volume. With that kind of scale everything is hard. It's just a different sort of hard than contended resources. Hell, even that is as "easy" these days with CRDTs (and I say this with dripping sarcasm).
Asset volume is just a price issue in these days. You can reduce the price by using clever caching, with programming language choices, or higher compression rate.. but in the end it is not a real problem anymore in the overall infrastructure architecture. Read-only assets can be copied, duplicated, cached without any worries that they might need to be re-synced soon.
Of course, how much, depends on the service. Particularly, how much concurrent writing is happening, and do you need to update this state globally, in real-time as result of this writing. Also, is local caching happening and do you need to invalidate the cache as well as a result of this writing.
The most of the relevant problems disappear, if you can just replicate most of the data without worrying that someone is updating it, and you also don't have cache invalidation issues. No race conditions. No real-time replication issues.