4 ms·

DNS is much easier to scale out than HTTP. By having full FQDN for users, you have the capability to easily scale out without needing a load balancer in front o

by jjoe 16y ago

DNS is much easier to scale out than HTTP. By having full FQDN for users, you have the capability to easily scale out without needing a load balancer in front of say, threewords.me. So in your DNS zone you can tell it to route all accounts that start with the letter 'a' to server with IP 1.1.1.1, letter b to IP 2.2.2.2, etc. Server with IP 1.1.1.1 will not only run a headless web app but also route SQL queries to a db shard (all relational data for users starting with the letter a). This level of "user" partitioning can be deeper. So it's not just the first letter of the user but two or three more letters/numbers. So joe.threewords.me would be on a different server than j4mes.threewords.me (That's j.o.threewords.me vs j.4.threewords.me). Regards Joe

adrianscott 16y ago
twitter has servers dedicated to high-volume users without having to use urls/dns like that.
- jjoe 16y ago
  "twitter has servers dedicated to high-volume users without having to use urls/dns like that" That's why they need so many load balancers w/ failover: twitter.com has address 128.242.240.148 twitter.com has address 128.242.245.212 twitter.com has address 128.121.243.228 Load balancers aren't flexible to work with especially when dealing with sessions. I imagine Twitter's front end nodes are doing nothing but routing URLs to backends, which are doing the real work. So the front end balancer takes http://www.twitter.com/unixy http://www.twitter.com/unixy and routes the actual server-side request internally (where scalability is implemented).