Rock, paper, scissors game with performance
When commercial airplanes were getting faster and faster it was becoming real that everyone will be travelling in supersonic speeds across the world before the end of the second millennium. Supersonic commercial flight was available in 1969, the same year humans went to moon. Supersonic flights never went mainstream, the demand simply wasn’t there for performance as it came with a huge cost. Eventually the supersonic flights have been stopped until we find an alternative that gives performance at a cheaper cost.
Rock, paper, scissors game is inevitable in performance. You will end up with tradeoff sliders like cost, time, performance, consistency etc and not be able to use all the sliders at once. Some aspects of performance are low hanging fruits, like not looping many times on a same list, N+1 queries which a programmer should definitely take care before getting into performance tuning. The last one should be throwing more hardware at the problem, which is too easy to do when one encounters a bottleneck.
Usage patterns are the key, ask questions like what parts of application needs to perform well? Does it get used often or is it one time like migrations? Can the application take a downtime/maintenance window? What is the likelihood of losing a customer to slow performance? The biggest mistake that makes you spend a lot of time and money is not coming up with non negotiable hotspots for performance.
Here are some games, there are plenty
- Indexing speeds up queries, but too many indexes slows down the db
- Prioritising synchronous calls leads to too much of backlog for async
- Each database/db type comes up with its own rock, paper, scissors game
- Increasing hardware, sharding, replicas and similar strategies will increase cost with increasingly lower returns
- Lot of async requires robust error handling mechanism
- Hand coding (working around framework or library) will increase upgrade /security risks and non maintainability
- Bullet proof security impacts speed
- Breaking into smaller services improves local performance, hammers back when you need network calls for rich data
