O'Reilly's Performance Optimizations in a Cloud-Centric World

Learn all you need to know about email best practices, deliverability, and tools with email whitepapers and ebooks.

Issue link: https://hub.dyn.com/i/545501

Contents of this Issue


Page 35 of 38

Feature toggles are designed to be short term, then to be removed after the feature is fully rolled out into production, as there is over‐ head in running and maintaining them. Longer-term feature tog‐ gles should only be considered for specific pieces of functionality that are part of a set plan to remove on demand. Examples of this may be predictive search that is triggered on every key press. If this uses a search system that's out of your control, then when you start to see problems with that service, you can change the toggle to remove predictive search. If the service starts to struggle even more, then you can change the toggle to remove search func‐ tionality completely. Fail Gracefully If there's no way to proactively handle the failure and prevent any impact on the user, then you need to ensure that your system will fail gracefully. The user should see a properly designed and presen‐ ted page with a helpful error message that explains what has hap‐ pened. If the failure happens within a data transaction, the user should be notified of the current state of the transaction (e.g., has their order been placed successfully?). Create a "Flight Manual" A "flight manual" should be created with mitigation plans associated with each type of failure. This should include the nature of the change that can be made and the circumstances under which it is acceptable to make that change. Having this sort of manual allows people on the ground to be empowered to make decisions and changes without having to go through a complex decision-making process with management. 26 | Chapter 3: Minimizing Performance Risks

Articles in this issue

view archives of eBooks - O'Reilly's Performance Optimizations in a Cloud-Centric World