Hacker News new | past | comments | ask | show | jobs | submit login

> "Sharding is always something you do on day 1 for every project ... SPOF ..."

Cannot agree with that. If one does that or not, would depend on things like Service Level Agreements (SLA) — and one can have a pretty high SLA uptime %, without sharding, e.g. if there's an underlying pretty stable hosting provider that live migrates if there's a hardware failure.

Thanks for writing about the last time you used Redis. Interesting to hear that, in that case, the machines had sth like 64 – 128 RAM, and 250k – 500k RPS. Yes I agree that I'd need to benchmark and think about what type of machine(s) to use (some time later — a bit too early for that now). Sounds as if you are / were a pretty large company / project, needing that much memory and machines :- )




Nope.

If you have one instance you better be damn sure that downtime doesn’t cause an an outage. IE. no redis means services still run.

The “it’s fine, the SLA covers outages” is just a) laziness and b) negligence.

You don’t do that with web servers, you don’t do it with databases. You don’t do it with your redis instance either.

...well, I suppose some people will do the it anyway; but you get what you get if you do.

If a major outage gets you fired, you have no o w to blame but yourself.


> Cannot agree with that. If one does that or not, would depend on things like Service Level Agreements (SLA) — and one can have a pretty high SLA uptime %, without sharding, e.g. if there's an underlying pretty stable hosting provider that live migrates if there's a hardware failure.

Sorry, no. A single instance is never acceptable from any risk perspective, no matter what guarantees the hosting provider claims.




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

Search: