3 ms·
All our scaling issues are database bound, but it seems all the auto-scaling solutions seem to tackle CPU-bound problems. Are we unique, or do most folks encou
by jgalt212 3y ago
All our scaling issues are database bound, but it seems all the auto-scaling solutions seem to tackle CPU-bound problems. Are we unique, or do most folks encounter CPU-bound scaling issues?
- deleted 3y ago[deleted]
- jiggawatts 3y agoMost startups use inefficient languages like Ruby, PHP, Elixir, or JavaScript. They also generally "move fast" and don't stop to optimise anything. So it's not unusual for their code to end up 10-100x slower than it could be if developed with something like ASP.NET. Additionally, many startups develop apps for scenarios where the database scaling can be solved. Typically they have many customers and can shard the data, or they can tolerate eventual consistency and hence can just throw caching layers at the problem. Transactional enterprise apps can't do this, they're single instance and caching could cause all sorts of weird data loss or corruption. Hence, the database becomes the most common bottleneck.
- walth 3y agoMost just utilize out of the box macro resources available in HPA. For more advanced use cases there is keda - https://keda.sh/ https://keda.sh/