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

Yeah, the database is under too much load right now (should have chosen RDS t3.micro when posting on HN). Updating to a bigger instance right now, should be up in a few minutes again. Thanks for the feedback


I imagine your entire database would fit easily in memory, so you should consider caching instead of hitting your database on every request.


I’m in the process of learning React to build Webapps and this sounds like something I’d need to know eventually, any resource recommendations?


No resources off the top of my head. I learned this stuff a pretty long time ago!

Deciding how to cache is often much more complicated than writing the actual code, although the code can also be very complicated.

For any caching layer, you have to decide:

- storage? (on disk vs. in memory)

- host? (app server vs. database server vs. third-party like ElastiCache)

- what to cache? (DB query results and/or rendered views and/or DTOs)

- when to delete cache? (ex: row #12 was changed in the DB, so now I need to delete any cached data that should change because row #12 was an input for it)

- how to segment cache? (logged-in users may share some parts of cache, but not others)

- TTL for cache? (is it OK to just keep everything in memory forever, or does there need to be a time limit that will reduce the size of the cache?)

- max size for cache? (same issue as above, but the limit is the storage size instead of a proxy like time)

These seem like decent jumping off points:

https://alankent.me/2018/08/25/server-side-caching-strategie...

https://www.digitalocean.com/community/tutorials/web-caching...

https://aws.amazon.com/caching/


Thanks for the starting point. I find one of the biggest challenges is figuring out what I should learn to be efficient (the unknown unknowns), so even just a point in the right direction is very helpful!


My suggestion would be, to not focus on that stuff right away. I know, this comes from the guy, whos website suffered the HN hug of death, but, look, I could bring it back up within 10 minutes.

My suggestion is, to build it as easy as possible, ideally with AWS or something like that, where you can throw computing power at it in a matter of minutes, when needed.

Build the stuff first, worry about scalability later, when you actually have proven that you need to worry about it. That's the lesson from my first startup anyways. We made the server slick and scalable, but in the end noone cared, because the product didn't meet demand. Don't waste your time on prematurley optimizing. Just my two cents :)




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

Search: