Jeff Kao

It's significantly over-provisioned now, which is why we're looking into how we can be more efficient about dealing with spikes.

We already actually shard out the database servers by different use cases and by different tiers of customers because we are a SaaS company, just to reduce or essentially just to isolate certain workloads and prevent outages from a bad query from one customer affecting others.

So we...

All that's to say is like we are quite over provisioned there, but we're working on it.

Yeah, that's right.

Cost cutting is like a, I wouldn't say it was the primary thing for getting this started, but we did see a lot of benefit from that.

So even running 30 nodes, we're able to replace, you know, a number of like Elasticsearch instances.

And we represented like geo queries in many different ways, like denormalized across different stores, stores like Redis and Mongo as well.

You know, and then in total, I would say actually, even with the 30 nodes, you

And over-provisioning.

We probably saved maybe mid to high five-figure monthly spending for some of these things.

Right.

So, on average...

Which is a misleading metric because for geocoding, which is search, is a very different workload from reverse geocoding.

We do 600 queries per second per box, and it's about 20 to 30% CPU at the steady state, which means it can go higher.

And I would say that, you know, our search workloads are probably like a 10x, sometimes even 100x of like reverse lookups as well as like primary key lookups.

Right.

So, you know, breaking it down into like the different use cases for geocoding, which is search query reverse geocoding, which is like a lat long lookup.

And then maybe even like primary key lookups.

I would say the latter two are more IO bound.