[minimax]

No offense to the Art.sy team, but this is just Heroku marketing copy. It lacks the detail we typically see on these sorts of high scalability "how we did it" posts. Non-trivial applications scale non-trivially, and when someone comes along claiming they have solved the scalability problem with the push of a button I am instantly skeptical.

I would really like to see more details about their architecture, especially about the MongoHQ integration.

[dblock]

I wrote a blog post on our overall tech stack here: http://artsy.github.com/blog/2012/10/10/artsy-technology-sta...

Our MongoHQ integration is very straightforward - MongoHQ provides us with a replica set and we configure it as any other MongoDB database.

Feel free to ask any specific questions.

[georgeorwell]

I realize this is off-topic but just as a bug report, I tried to search for "cezanne watercolor" and it didn't understand, despite that you have watercolors by Cézanne. Also it wasn't clear whether watercolors were best found under "paintings" or "works on paper". I think you need to make it easier for non-computer people to find specific types of image.

[dblock]

It's an interesting observation. We built a full text semantic search in 2011 by reverse-indexing art search results from popular search engines and it could do things like "Cezanne watercolors" at ease.

We showed it to people and we found that one could easily trick the system with things like "Worst American Art Ever". That generates results, but shows the limits of a general semantic search in a narrow context.

Happy to hear any suggestions about how to make something like this both useful and not too easy to make look really silly.

[georgeorwell]

Well surely each of them is tagged with both 'cezanne' and 'watercolor', can't you just match search substrings to tags?

[dblock]

It only works in that case. What if there's another work that is called "Cezanne's Favorite Watercolor", and we're just in the beginning of search hell :)

[continuations]

> we use SendGrid and MailChimp to send e-mail.

Why do you use both SendGrid and MailChimp for email?

Can you talk about the different use cases that require using the different email services?

[redguava]

I don't know about how they do it, but I use both currently.

SendGrid for one-off emails (ie. a user signs up for an account, their welcome email).

MailChimp for email marketing (we send newsletters via them).

MailChimp has since released Mandrill that caters to the one-off emails, but we were already with SendGrid by then.

[dblock]

Same thing for us at Art.sy. We have humans doing targeted emails, with MailChimp.

Sendgrid is an SMTP relay with high deliverability. That's all it does. You can find who received what on the website, too. With MailChimp you have to setup lists and all that unnecessary stuff.

There's one big drawback to using both: we currently have to sync our users to MailChimp and sync MailChimp unsubscribes back. Hence we're going to get rid of MC eventually when we can build good enough UI to manage mass emails.

[continuations]

I see. What make SendGrid better for one-off emails and MailChimp better for email marketing?