Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It’s bullshit. A majority of high volume systems can do this just fine. This is just engineering wank.

Standard solution is query a session table on from a single location, and once you actually start to need to trim request time, it’s not even the first place you look.



Assumptions you are making:

* everything is located physically close together (good luck reading from a DB table in Singapore from a service in Europe for every request)

* you have few enough client services that want to do this that the number of db connections does not become a problem (this is 100 by default for Postgres, you might need to tune this or deploy proxies, etc)

* high availability is already taken care of (you don't want that one DB server to bring down everything in case of a failure)


several comments up this branch we were talking about middle ground, remember


Yes. It's super common for SaaS companies that are <1% the size of Google to have infrastructure in multiple regions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: