[swindsor]

1. Good point - I didn't bring this up in the article. When we store the images locally, we create divide end of the unique ID of the image into two levels of subdirectories. This gives us "random enough" distribution in subdirectories, and an easy way to look up the files on disk. This logic exists in our rails app, but we didn't want to expose this pathing out to end users. This allows us to change it later if we need to create further subdirectories.

2. Good tip - we try to use our judgement here balancing good design/good performance. We tend to opt for a pretty website first, then go back and make it faster with optimization.

[zepolen]

Regarding "This logic exists in our rails app, but we didn't want to expose this pathing out to end users". I'm not sure if you understood, but I'm saying exactly this. nginx will take a /whatever request and convert it to /w/wh/wha/whatever on disk transparently - you can (and I have needed to) change this whenever you like with no front facing changes.

[swindsor]

Oh, that's cool - I didn't know you could use matches from a location in an alias. Is that a new feature in nginx?

[zepolen]

I think it's always been a feature of nginx:

    location ~ "/(.*)" {
        root /whatever/$1;

You could even do:

        set $subdir $1;

so that it can be used in another location handler.