Live data from Hacker News

Scaling lessons learned at Dropbox (2012)

eranki.tumblr.com

31–32 of 32 posts

Re: Scaling lessons learned at Dropbox (2012)

#31
> For instance, almost every website has a thing where if you enter in a wrong username OR wrong password it’ll tell you that you got one wrong, but not tell you which one. This is good for security because you can’t use the information to figure out usernames, but it is a GIANT pain in the ass for people like me who can’t remember which username they registered under. So if you don’t actually care about exposing usernames (maybe on something like a forum or Pinterest where they’re public anyway), consider revealing the information to make it more convenient for users.

YES! Such a pain in the arse for a tiny theoretical unimportant security benefit. In some situations it is warranted, e.g. dating sites. For something like Amazon or Wikipedia who cares if you know that I've registered there?

Re: Scaling lessons learned at Dropbox (2012)

#32
post #8

"One technique we repeatedly used was creating artificial extra load in the live site. For example, we would do a lot more memcached reads than necessary. Then when memcached broke, we could quickly switch off the duplicate queries and have time to come up with a solution." As much as I want to hate this, it's actually genius and elegant in its simplicity.

I do something similar with disk usage. Create a dummy file with XX GB and delete it when you are running out of space

I worked at a shop where they didn't bother with a partitioning scheme - everything was just one large volume. The amount of times I've had to do emergency cleanup on production servers...
Post reply on HN