Working with various projects using MySQL I observe a lot of problems are coming from very simple fact - product is designed containing features which developers do not know how to implement effectively.
In many companies you would see “waterfall” like approach for web application development at least on business-development boundary. Business people would dream up some features for developers to implement which developers simply take and implement as good as they can - unfortunately often not good enough to match performance and scalability requirements for the application.
In the end such approach may have nasty surprises - application gets serve performance problems due to features which might be not critical after all and even Business people would rather make things running fast than having these features working exactly as required.
So what is my point ? Only plan for features which you know how to implement to match your performance goals. If you do not know how to implement something performing well - do not implement it at all. Sometimes you can find our similar feature may be implemented working much faster way, in other cases it may be most efficient to ask for help or search for help - most problems you’ve got to deal with in web applications are already solved by someone in one form or another.
Talk to Business People They may not agree to give up features they have designed but still would like to note it will require 30 servers instead of planned 10.
Make sure you both understand performance requirements This is probably problem with smaller companies rather than big ones - sometimes speaking to developers and business people you would see very different performance metrics.
For example Business guys often forget “bots” in their planning which may be responsible for 50-70% load for some projects.
In many cases poorly implemented features are actually fine from business point of view - they still work fine on the load and the database size in question. Just make sure you know when things are expected to stop working.
Doing architecture review I always ask what growth patterns for database size and load is expected - if growth is slow it might be easily to solve things which are not created scalable with extra hardware, if growth is fast implementing things differently is often needed.


Only Design What You Can Implement - Read More...