Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Absolutely not. This is an average, I bet their peak could be in the mid hundreds of thousands, imagine a hype moment in a LCS game.

It can in theory work, but the real world would make this the most unstable platform of all the messaging platforms.

Just one vacuum would bring this system down, even if it wasn't an exclusive lock... Also I would be curious how you would implement similar functionality to the URL deep linking and image posting / hosting.

Mind you the answers to these will probably increase average message size. Which means more write bandwidth.

Some bar napkin math shows this would be around 180GiB per hour, 24/7, 4.3TiB per day.

Unless all messages disappeared within 20 days you would exceed pretty much any reasonable single-server NVME setup. Also have fun with trim and optimizing NVME write performance. Which is also going to diminish as all the drives fail due to write wear...



Absolutely not. This is an average, I bet their peak could be in the mid hundreds of thousands

That's my point. Per-second numbers are far more useful than per-day numbers.


> useful than per-day numbers

Useful for what exactly? You're basically accusing the company of inflating their numbers (??) as if they are deliberating lying about their scale.


As zorkian noted, "messages per day" is a marketing number. In a technical blog post, what matters is the numbers which are relevant for technical purposes, such as peak (or high-percentile) messages per second.


In a technical blog or dashboard I like to see

1) avg mean (for throughput estimates), 2) p50 (typical customer / typical load), 3) p90 / p99 / p99.99 (whatever you think your tail is) 4) p100 (max, always useful to see and know, maybe p0).

Or throw in a histogram or kernel density estimate, sometimes there are really interesting patterns.

I’ve never seen a technical blog give such traffic or latency details though.

Edit: reading other comments, please do not read this as diminishing this blog post or Discord, great clear writing and impressive solution to an interesting problem.


> blog post

It's a blog...it IS marketing.


So add a Redis node or two as cache - exactly the same kind of things they did basically.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: