Live data from Hacker News

How We Built r/Place

redditblog.com

41–50 of 255 posts

Re: How We Built r/Place

#42
post #20
post #6

> Users can place one tile every 5 minutes, so we must support an average update rate of 100,000 tiles per 5 minutes (333 updates/s). It only takes a couple of outliers to bring everything down. I'm not exactly well-versed in defining specs for large scale backend apps (not a back-end engineer) but it seems to me that preparing for the average would not be a wise decision? For example, designing with an average of a…

They might have phrased this poorly. >We should support at least 100,000 simultaneous users. This line makes me think that this is what they expected the peak (or near peak) to be. >Users can place one tile every 5 minutes, so we must support an average update rate of 100,000 tiles per 5 minutes (333 updates/s). So assuming that they mean that 100k is the peak and that clients are limited to 1 update per 5 minutes, t…

Prepare for the average and hope for the best seems like a great way for things to fail.

Re: How We Built r/Place

#43

Given the scale described, it sounds like they could have had a single machine that held the data in memory and periodically flushed to disk/DB to support failing over to a standby.

You're basically describing how we used redis for this project.

Re: How We Built r/Place

#44
post #34
post #27

Earlier quoted context omitted.

Pages take a long time to generate all day, but during peak hours they take a minimum of 4 seconds each (depends on what page you're loading, if it's got lots of comments, etc), and many times they simply timeout. The engineers at reddit have been unable thus far to fix it.

This isn't my experience.

I'm not the same guy you were just talking to but in my experience on mobile Safari, I get "something went wrong, visit the homepage" when I navigate around reddit far too often. What's funny is it actually tends to resolve itself if I wait a second or two, but yeah, reddit engineering and infrastructure is not well equipped to handle the amount of traffic they receive. It's gotten better, but it's still not what you'd expect from the internet's front page.

Re: How We Built r/Place

#45
post #31

So I got hit by an unfortunate bug on the first day of /r/place. I was trying to draw something, one pixel at a time, and all of a sudden, after a bunch of pixels, it stopped rate-limiting me! I could place as many as I wanted! So I just figured that they periodically gave people short bursts where they can do anything. This was backed up by my boss, who was also playing with /r/place, saying that the same thing happ…

It happened to me as well. I did verify that my changes actually made change (from the same IP, but in incognito mode). Didn't bother to check if the changes stayed.

Re: How We Built r/Place

#46

Given the scale described, it sounds like they could have had a single machine that held the data in memory and periodically flushed to disk/DB to support failing over to a standby.

That was my thought as well.

Re: How We Built r/Place

#47
post #14
post #6

> Users can place one tile every 5 minutes, so we must support an average update rate of 100,000 tiles per 5 minutes (333 updates/s). It only takes a couple of outliers to bring everything down. I'm not exactly well-versed in defining specs for large scale backend apps (not a back-end engineer) but it seems to me that preparing for the average would not be a wise decision? For example, designing with an average of a…

The entire reddit website goes down every night, especially during weekends, sport matches, etc, so there you have your answer.

maybe three years ago it did, but reddit has gotten drastically more stable since then. It still has the occasional downtime, but now it's more like every couple months than every couple days.

Re: How We Built r/Place

#48
post #42
post #20

Earlier quoted context omitted.

They might have phrased this poorly. >We should support at least 100,000 simultaneous users. This line makes me think that this is what they expected the peak (or near peak) to be. >Users can place one tile every 5 minutes, so we must support an average update rate of 100,000 tiles per 5 minutes (333 updates/s). So assuming that they mean that 100k is the peak and that clients are limited to 1 update per 5 minutes, t…

Prepare for the average and hope for the best seems like a great way for things to fail.

They prepared for the worst (peak 100k users). The "hope" that those 100k would be spread out was based on the statistical likelihood that these 100k wouldn't line up too much over a 5 minute period.

I didn't follow /r/place that much, but I haven't read any complaints about latency or failures so it looks like they did just fine.

Re: How We Built r/Place

#49
post #28

Now I'm curious, Are there any websites that do something similar to /r/place? (hackathon idea?) Also, reminds be of the million dollar front page [1]. [1] https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage

Actually this idea has been around for years, and sadly isn't new at all. I just checked and there is one that's been around since at least 2006, http://da-archive.com/index.php?showtopic=42405

I remember lueshi

Re: How We Built r/Place

#50
post #2

> We actually had a race condition here that allowed users to place multiple tiles at once. There was no locking around the steps 1-3 so simultaneous tile draw attempts could all pass the check at step 1 and then draw multiple tiles at step 2. This is why you use a proper database. I'd probably add a Postgres table to record all user activity, and use that to lock out users for 5 minutes as an initial filter. Have tr…

Well PostgreSQL is a single master for writes so it doesn't scale well to say the least.
Post reply on HN