What I learnt from Peak planning

  1. Every thing developed right from the design time must be performance oriented . So when there is a design being planned it should not be concentrated only on output but how the output is being achieved. So for example in one of previous orgs the developer working on a payment system used polling rather than a webhook and imagine how the performance has been affected although objective was met.
  2. Caching mechanisms play a great role. Now many engineers believe that caching and datastructures all this matters only for search based companies and for social networking giants. But that is completely wrong.
    There should be stress and evaluation on what sort of cache to be implemented and the caching mechanism to be followed. This helps a lot in enhancing the customer experience.
  3. Streaming systems. Widely used nowadays but becomes pain when implemented in wrong manner. Again in one of the previous orgs the streaming system was something which resulted in double entries for every commission that was suppose to go to a vendor. Now in such cases we should evaluate and plan our streaming mechanism. Whether a need for back -pressure protocol is there or not needs to be evaluated. Even the consumer whether that can perform best with this streaming system must be evaluated.
  4. Rate limiter. Now rate limiter does not apply only at the load balancer level. But based on business goals and also on diverse geographies where we serve rate limiting needs to be implemented at API level. Thus to some extent cutting down on DDOS threat.
  5. Doing performance testing in religious manner. Load testing should happen in strict manner . Not from some laptop over an internet connection. It should have proper test bed. There should be proper dashboard to capture all metrics. The IOPS must be considered. The old data must be used to derive the BUSINESS AS USUAL metrics and then implement the same. A performance testing being done in sincere manner yields best of the best results during peak hours.
  6. Logs as mentioned earlier can be bane if too much is logged. For this logs must be cut down and what needed must be only logged. printf and System.out.println() such things must not be allowed by implementing strict sonar rules. Also SONAR rules must be implemented to check variable declarations are proper or not. If something can be handled using static then that is best way rather than creating new instance every time.
  7. Implementing certain business rules to cut down on high incoming volume. Definitely cannot comment much on this as this is something internal.



Productivity Engineer at Narvar . Data Science enthusiast. Boxer by passion

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store