One wonders if Yelp could just run on a basic Postgres setup. It's not too much data, the data is relatively unimportant and the traffic is modest and mostly from US. How do the setups get so complicated?
The specs called for a Kubernetes cluster and a Cassandra database cluster for production and the same for testing. Everything about this project was presented as being highly complex. Digging into it with the client and the developers we reduced it to: One Docker container running in Azure websites and CosmosDB on the backend, which could basically run on the free tier.
The whole thing hold less than 3GB of data and had maybe a few hundred requests per day. The client just loved the idea that they where special, dealing with massive amount of data and required scalability to keep costs under control. The developers more or less just ran with it and wanted to do Kubernetes and Cassandra sounded interesting and now they had a client that would pay for it. Technically I suppose that both Kubernetes and Cassandra where reasonable choices, had they had 1000x the load, but given their market they where never going to grow beyond 10x on this particular solution.
We didn't get the contract. Our bid was insanely low (not really worth the cost of bringing in a new contractor), delivered something different that asked for (fair enough).
I see a small hosted k8s setup with a hosted sql server as a fine app for many things.
In this case you had a potential zero management environment, truly Cloud as it was meant to be, vs. managing Kubernetes, plus a database. You could go with managed Kubernetes (AKS) and a managed SQLServer, but why take on that cost?
Edit: Even AKS isn't truly zero management, you need to do at least some of the work for the upgrades, so instantly more management, something you need to do, something that adds to the operational cost.
I have personally never build an app that was a single docker image running. Usually I am at a min of 2. One server going down shouldn't take down prod once you even have 1 paying customer.
There were half a million restaurants back then or thereabout, and they wanted to store ratings and comments.
That is not something you'd be able to put on one single database in 2004.
Why didn't they simplify afterward I can't imagine, but I can see how a business directory at that age looked at the numbers and went yeah not in a database.
Back in 2004 I was running larger MySQL databases than yelp has now:
https://www.enterpriseappstoday.com/stats/yelp-statistics.ht...
> That is not something you'd be able to put on one single database in 2004.
Sorry, but it was, plenty of companies had much larger databases back then running plain old master slave replication.
But even if it wasn't: just don't run it all on one db? Nothing says you need to be able to join on the restaurant table and the comments table. Put them on different servers. That's all you're doing with Casandra anyway.
Also, whether you need a highly available database for a company like yelp is an implementation detail.
Oh no, the database is down, how will Jonny decide where to go for lunch now?!
> Also, whether you need a highly available database for a company like yelp is an implementation detail.
You surely know better than them what they need, that's impressive.
I used to work at Yelp, and at least at that time, a big use case of Cassandra was basically for what were essentially materialized views created from log data. At that point in time, MySQL or logs were the "sources of truth", but there were enough transactions going on that it made sense to have things like Cassandra around too for some of the other use cases.
Whether they really needed cassandra or whether it was just using fancy complicated tech for the sake of it, I couldn't say.
1. In one case, developers hate DBAs and MongoDB is outside the scope of DBAs.
2. A developer starts using CouchDB to include in the curriculum.