Scalability and Performance

Scalability is an all time favourite subject in my entire professional career. When developing the first version of an application, you often do not have any scalability issues. Moreover, using a distributed architecture slows development. This can be a major problem for startups whose biggest challenge is to rapidly evolve the business model and reduce market time. Its is one of the most critical conditions for the success of a web application. In this article, I will define what to keep in mind during development phase in order to meet the principles of scalability.

To build a scalable application, you need to keep the following points in mind:

    1. Distribute API development: The system should be designed in such a way that multiple teams can work on it simultaneously, and a single team should not become a bottleneck, nor does it need to have expertise on the entire application.
    2. Support multiple languages: In order to take advantage of emerging technologies, every functional part of the system should be able to support the language of choice.
    3. Minimize latency: The architecture that we propose should try to minimize client’s response time.
    4. Minimize deployment risks: Different functional components of the system should be able to be deployed separately with minimal effect on current running system.
    5. Minimize hardware footprint: System should try to optimize the amount of hardware used and should be scalable horizontally.

Scalability is an overloaded term. We can further categorize it into 4 main parts:

    • Scalability of Performance
    • Scalability of Availability
    • Scalability of Maintenance
    • Scalability of Expenditures

Each of these are important to consider when we design our applications. Some of these aspects overlap, some even contradict each other at times. There are certain Design Principles that we should follow while aiming at a highly scalable application. I have listed the Design Principles that I believe in in the section underneath:

Scalability Design Principles

  1. Avoid the single point of failure. We can never just have one of anything, we should always assume and design for having at least two of everything. This adds costs in terms of additional operational effort and complexity, but we gain tremendously in terms of availability and performance under load. Also, it forces us into a distributed-first mindset. If you can’t split it, you can’t scale it has been said by various people, and it’s very true.
  2. Scale horizontally, not vertically. There is a limit to how large a single server can be, both for physical and virtual machines. There are limits to how well a system can scale horizontally, too. That limit, though, is increasingly being pushed further ahead. Even databases are moving in that direction. Furthermore, the cost of (vertically) upgrading a server increases exponentially whereas the cost of (horizontally) adding yet another (commodity) server increases linearly.
  3. Push work as far away from the core as possible. There are several orders of magnitude more clients than servers as we move inward into the core of our application. The less work the few have to do on behalf of the many, the better. The smaller the updates we can pass to our clients, the better.
  4. API first. In addition to pushing work to the clients, view your application as a service with an API first. Clients these days are smartphone apps, web sites with JavaScript, and desktop applications. If the API does not make assumptions about which clients will connect to it, it will be able to serve all of them. And you open your service up for automation, as well.
  5. Cache everything, always. Caches are essentially storages of precomputed results that we use to avoid computing the results over and over again. This is a Godsend for scalability and performance, so we must use it.
  6. Provide as fresh as needed data. Depending on your application, users might not need the very freshest data right away. Eventual consistency leads to much better availability under the CAP theorem. If we actually need strict consistency, so be it.
  7. Design for maintenance and automation. Software needs monitoring and updates to ensure proper operation over time. As we move out of the servers are pets era and into the servers are cattle era, our mindset has to change. Do we even need to reconfigure servers anymore? Can’t we just take old ones down and replace with new ones, that have been configured offline as part of their image creation? What monitoring data is important to us? What information does it provide us with? Do not under-estimate the time and effort spent in maintaining your application. Your initial public software release is a laudable milestone, it also marks when the real work begins.
  8. Asynchronous rather than synchronous. We already understand asynchronous communication perfectly in the physical world. We drop off a letter in the mail, and some time later, it arrives. Until it does, we convince ourselves that it is underway, oblivious to the complexity of the postal system. We only use personal couriers for very important messages. A similar approach should be taken for our applications. Did a user just hit submit? Tell the user that the submission went well, and then process it in the background. Perhaps show the update as if it is already completely done in the mean time.
  9. Strive for statelessness. While it may seem tempting to avoid inter-component communication by keeping track of certain state information in e.g. your application servers, don’t. Unless we host purely static pages, we can never get away from state information. We must make sure that state information is kept in as few places as possible, and within components made for it. Web and application servers are not, but distributed key-value stores. Keeping it there lets you treat your web and application servers as completely replaceable instances, which is ideal from a scalability point of view since your server fleet can much more easily be modified when any server is able to handle any client request (despite the client being in the midst of a “session”).
  10. This too shall fail. Computer systems fail. Software fails. Hardware fails. Designs fail. Failure handling fails! Be prepared for failure, but spare end users from witnessing it too obviously. It reflects poorly on you, even if failure is inevitable.
    Here, I list some common Design Rules derived from design principles:

      1. Ensure your design works if scale changes by 10 times or 20 times.
      2. Do not use bleeding edge technologies.
      3. Optimize the design for the most frequent or important tasks.
      4. Design for horizontal scalability.
      5. Design to use commodity systems.
      6. Design to Leverage the Cloud.
      7. Use caches wherever possible.
      8. Design scale into your solution.
      9. Simplify the solution.
      10. Performing I/O, whether disk or network, is typically the most expensive operation in a system.
      11. Transactions use costly resources.
      12. Use back of the envelope calculations to choose best design.

Fintech: The Experience so Far

Digital transformation has taken a hold of the financial services industry. Today’s banking landscape has been divided into two main roles: traditional financial institutions and disruptive fintech applications. While the differences between the two are stark, a shared goal remains: improving the customer experience.

परख

परख – एक कथा

एक मन्दिर में एक संन्यासी रहा करते थे। मंदिर के ठीक सामने ही एक वैश्या का मकान था। वैश्या के यहाँ रात−दिन लोग आते−जाते रहते थे। यह देखकर संन्यासी मन ही मन कुड़−कुड़ाया करता। उस संन्यासी ने यह हिसाब लगाने के लिए कि उसके यहाँ कितने लोग आते हैं एक−एक पत्थर गिनकर रखने शुरू कर दिये। एक दिन वह अपने को नहीं रोक सका और उस वैश्या को बुला भेजा। उसके आते ही फटकारते हुए कहा— ‟तुझे शर्म नहीं आती पापिन, दिन रात पाप करती रहती है। मरने पर तेरी क्या गति होगी?”

संन्यासी की बात सुनकर वेश्या को बड़ा दुःख हुआ। वह मन ही मन पश्चाताप करती भगवान से प्रार्थना करती अपने पाप कर्मों के लिए क्षमा याचना करती। बेचारी कुछ जानती नहीं थी। बेबस उसे पेट के लिए वेश्यावृत्ति करनी पड़ती किन्तु दिन रात पश्चाताप और ईश्वर से क्षमा याचना करती रहती। हमेशा की तरह, संन्यासी ने, जब कोई आता एक पत्थर उठाकर रख देता। इस प्रकार पत्थरों का बड़ा भारी ढेर लग गया तो संन्यासी ने एक दिन फिर उस वेश्या को बुलाया और कहा

“पापिन? देख तेरे पापों का ढेर? यमराज के यहाँ तेरी क्या गति होगी, अब तो पाप छोड़।”

पत्थरों का ढेर देखकर अब तो वेश्या काँप गई और भगवान से क्षमा माँगते हुए रोने लगी। अपनी मुक्ति के लिए उसने वह पाप कर्म छोड़ दिया। कुछ जानती नहीं थी न किसी तरह से कमा सकती थी। कुछ दिनों में भूखी रहते हुए कष्ट झेलते हुए वह मर गई।

क्या पता था, उस संन्यासी का भी समय आ चुका था, वह भी चल बसा।

सच के दरबार में जब पेशी हुई, तो संन्यासी को सज़ा सुनाने वालों की तरफ़ रखा गया और वेश्या को माफ़ करने वालों की तरफ़ । तब संन्यासी ने बिगड़कर कहा “तुम कैसे भूलते हो। जानते नहीं हो, मैंने कितनी तपस्या की है त्याग किया है”

सत्य बोले “हम सबकी असल जानते है। असल तो यह है वह वेश्या पापिन नहीं है पापी तुम हो। उसने तो अपने पाप का बोध होते ही पश्चाताप करके सच्चे हृदय से भगवान से क्षमा याचना करके अपने पाप धो डाले। अब वह मुक्ति की अधिकारिणी है और तुमने सारा जीवन दूसरे के पापों का हिसाब लगाने की पाप वृत्ति में, पाप भावना में जप तप छोड़ छाड़ दिए और पापों का अर्जन किया।

भगवान के यहाँ मनुष्य की भावना के अनुसार न्याय होता है। बाहरी बाने या दूसरों को उपदेश देने से नहीं। परनिन्दा, छिद्रान्वेषण, दूसरे के पापों को देखना उनका हिसाब करना, दोष दृष्टि रखना अपने मन को मलीन बनाना ही तो है।

संतों ने कहा है –

परख करोगे तो परख होगी। 

क्षमा करोगे तो क्षमा मिलेगी, हम अपने आपको भी क्षमा कर पायेंगे।

हमें अपनी भावनाओं को – विकारों में ( पाप, घृणा और निन्दा) डुबाये रखने की अपेक्षा सद्विचारों में ही क्यों न लगावें? क्यों न अपनी चेतना को परमात्मा के चरणों ने लगायें।

या जग में कोई सुख न देखो

श्री हज़ूर स्वामी जी महाराज ने एक जगह फ़रमाया है –

या जग में कोई सुख न देखो | गहो गुरु के बचननियाँ ||
दुःख के जाल फँसे सब मुरख | तू क्यों उन संग फंसननियाँ ||

मेरी समझ से, स्वामी जी महाराज के भाव है-

हमें लगता है कि इस दुनिया में लोग सुखी है लेकिन असलियत यह है कोई भी जग में सुखी है नहीं, सारे ही दुःख के जाल में फँसे जा रहे है, इसलिए आप समझते है हम क्यों उनके साथ फँसते जा रहे है, हमें तो हमें गुरु के वचनों पर चलना है।

सब घट मेरा साइयाँ

कबीर साहिब ने फ़रमाते है –

सब घट मेरा साइयाँ, सूनी सेज न कोय ||
बलिहारी वा घट्ट की, जा घट परघट होय||

भावार्थ – हर घट यानी शरीर के भीतर, मेरा ही परमात्मा (साइयाँ) निवास करता है।  कोई भी उससे (रब से) खाली नहीं है| जिसका मतलब यह है, परमात्मा का घर, कहीं बहार नहीं है, वह घर हम सब के अन्दर ही निवास करता है|

लेकिन उस घट यानी शरीर यानी जीव की बलिहार है, जिसके घट में वह (रब) प्रगट होता है।