Live data from Hacker News

Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

highscalability.com

11–20 of 88 posts

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#11
According to the article Pinterest is spending on AWS EC2 >$30k to support 18M visitors/month.

Data: $52/h (peak time, let's say 18 out of 24 hours) and $15/h (night time, let's say 6/24).

Edit: as pointed in the comments $30k/month would only be the EC2 costs.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#12
post #10

Those kind of articles makes me feel so stupid. Even though those technologies are ready to go, making them work smoothly without any interruption always seems hard to me. I believe, there has to be lots of tips and trick. ( in other words you have to be experienced with all them or I am very lazy) I was wondering if any common receipt exists or if there is someone who can answer my couple of high scalability questio…

Yes, see "heavily-modified Django"

(even though this is probably around scalability and connecting with other technologies)

Scalability and uptime is still hard

Still, Pinterest is laying on a great infrastructure (EC2, Elastic Map Reduce) and using it to the fullest.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#13
post #11

According to the article Pinterest is spending on AWS EC2 >$30k to support 18M visitors/month. Data: $52/h (peak time, let's say 18 out of 24 hours) and $15/h (night time, let's say 6/24). Edit: as pointed in the comments $30k/month would only be the EC2 costs.

You are just counting EC2 cost. The AWS cost for 410TB of S3 storage is around $39k. You would need to add in BW cost on top of that.

It is also interesting that they seem to be using Akamai for a CDN instead of Cloudfront so not a completely AWS based solution.

I wish they went into what they are storing in S3. 410TB is a lot of storage. My initial guess was cached images but 80M objects breaks down to 5MB per object and that is a lot more than what is needed for image caching.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#14
post #2

They have a very Interesting Stack as seen on Quora[1]: -Python + heavily-modified Django at the application layer -Tornado and (very selectively) node.js as web-servers. -Memcached and membase/redis for object and logical-caching -RabbitMQ as a message queue. -Nginx, HAproxy and Varnish for static-delivery and load-balancing. -Persistent data storage using MySQL. -MrJob on EMR for map-reduce. [1] http://www.quora.co…

Pardon my ignorance: what is interesting about Pinterest stack? I think by now most startups, YC or not, in Silicon Valley will pretty much have a similar setup: 1) Choose the main web-stack (Rails or Django) 2) Choose the API framework (node.js, or something else) 3) Memcached for caching (or some NoSQL) 4) A message queue (ZeroMQ, RabbitMQ, or something ...) 5) nginx, HAProxy, Varnish, (or similar technology) 6) Ha…

Oh, I wish it was that simple.

You can't mix and match (you can theoretically)

Let's say you began with Django, right? Or there was something already ready in Django.

And then you begin to see the warts. But ok, you keep churning along.

And the more you churn the more of a specialist in the deficiencies of each technology you become. Like the fact that Django's ORM runs like a dog.

Or see all the "we moved to MongoDB and we regret it" discussions

From that list, there are two technologies I would recommend strongly (if you know what you are doing): nginx and Redis

The rest needs to be handled with care. And Redis is very powerful if you know how to use, but it's easy to go the "lazy way" with it, and it will be fast, but not as fast as it can.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#16

It's nice to see that two companies valued at >= $1 billion are running a Python/Django stack. #teampony

Yeah, I'm actually in the process of switching to Python/Django from Rails, so its great to hear how well it scales.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#17
post #13
post #11

According to the article Pinterest is spending on AWS EC2 >$30k to support 18M visitors/month. Data: $52/h (peak time, let's say 18 out of 24 hours) and $15/h (night time, let's say 6/24). Edit: as pointed in the comments $30k/month would only be the EC2 costs.

You are just counting EC2 cost. The AWS cost for 410TB of S3 storage is around $39k. You would need to add in BW cost on top of that. It is also interesting that they seem to be using Akamai for a CDN instead of Cloudfront so not a completely AWS based solution. I wish they went into what they are storing in S3. 410TB is a lot of storage. My initial guess was cached images but 80M objects breaks down to 5MB per objec…

From these figures they seem to burn over 100k per month on outsourced cloud services alone. Holy shit.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#18

It's nice to see that two companies valued at >= $1 billion are running a Python/Django stack. #teampony

Yeah, I'm actually in the process of switching to Python/Django from Rails, so its great to hear how well it scales.

I'm curious as to why you're switching. Care to share? I'm a long-time Django guy who's just been thrown into some Rails projects so I am going to be learning it shortly.

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#19
> Sharding is used, a database is split when it reaches 50% of capacity, allows easy growth and gives sufficient IO capacity

Nice, compared to the usual, "The database was at 100% capacity, then we tried to shard/partition, and it did not go too well."

Re: Pinterest Architecture Update - 18M Visitors, 10x Growth, 12 Employees, 410 TB

#20

Earlier quoted context omitted.

Pardon my ignorance: what is interesting about Pinterest stack? I think by now most startups, YC or not, in Silicon Valley will pretty much have a similar setup: 1) Choose the main web-stack (Rails or Django) 2) Choose the API framework (node.js, or something else) 3) Memcached for caching (or some NoSQL) 4) A message queue (ZeroMQ, RabbitMQ, or something ...) 5) nginx, HAProxy, Varnish, (or similar technology) 6) Ha…

Oh, I wish it was that simple. You can't mix and match (you can theoretically ) Let's say you began with Django, right? Or there was something already ready in Django. And then you begin to see the warts. But ok, you keep churning along. And the more you churn the more of a specialist in the deficiencies of each technology you become. Like the fact that Django's ORM runs like a dog. Or see all the "we moved to MongoD…

Yes, but the Django ORM helped them launch faster. There is nothing wrong using it to start with and then writing your own SQL queries when you need to scale or even changing your data model to accommodate scaling.
Post reply on HN