Agreed, this seems silly to build your own which likely performs worse than PosgGIS and has way more bugs.
At least the article could have addressed why that would not work for their use case.
edit: also now they have to classify polygons into groups that wholly fit into some "city" polygon. That seems like it becomes a pain to maintain since you may want to expand a region in the future and it happens to go outside of your previously defined "city". Or maybe you want a region that isn't in a "city", like a "country" or "mid-atlantic" region.
Most things at Uber were first built in the natural "why don't you just" way. Python/Flask monolith, Postgres, haproxy, etc. They are being replaced with fancier distributed systems (microservices, Schemaless, Ringpop, etc) by necessity.
Has the transaction rate surpassed what you can get out of Postgres? If not, what is the necessity for the change? Just curious. Thanks for any insight.
Increased latency, probably. They said they wanted 99% of queries to be 100ms or less. When I use the pgAdmin and run EXPLAIN ANALYZE SELECT 1; I get 0.025ms execution time, but it takes 62ms to send and recieve that.
Or MongoDB geospatial indexing? I used it for a project that required a similar approach (point in polygon). It was quite easy to setup and use, at least at a small scale.
