| Sep 18, 2017

4 MIN READ

Written by Ajit Gadge
API and Microservices

Going beyond ‘Active-Active’ design considerations

Many times, when I am talking to larger enterprises about their database designs, I get to hear the term ‘Active-Active’ as a requirement from customer side. I usually ask customers to specify what exactly are they looking for it. Most often, they start telling the features of some commercial database vendor. But I press further to understand the customer’s own requirement and then customers start telling what exactly they have in mind.
In this article, I am going to demystify the notion of ‘Active-Active’ and spell out what few things customers are looking for their database design requirements.
First of all, most of the time customers are asking for database load balancing features. Secondly, they are looking for database design that would grow with their requirements, they want to have high availability solution and lastly, they want that investment made in hardware and software licensing be utilized to the fullest so that they can justify the investments.
To help customers achieve these requirements, I usually start with the discussion on RPO and RTO. This discussion throws more light on customer’s business requirements and helps to arrive at a design document.
Let us look at what is RPO and RTO.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are very important parameters for businesses continuity. RTO is basically how long you can sustain without system being available for business when there is an outage. In other words, how much time does it take to restore your system in outage situation. Ex. If you RTO is 1 hour and during the outage your engineer is able to restore the system in less than 1 hour then you are within RTO parameters.
RPO is basically for what time frame is the data loss you can tolerate during and after the outage. In other words, up to what point in time could the business process recovery proceed, tolerating  given volume of data lost during the interval.
Ex : During the outage if your engineer is able to recover data less than 1 hour of business time and your RPO is 1 hour then you are within RPO. That data loss may be 100 MB or 1 GB does not matter.
Now it’s clear that any business decision makers would want to have minimum data loss with an acceptable time for recovery. So lesser the RPO and RTO, better for the business. But this kind of a setup comes up at an extra cost and with extra efforts. So the goal is to minimize RTO and RPO with least cost and minimum efforts.
Now lets us look at our other points, i.e. How to achieve a high scalability solution?
With High Scalability solutions, most enterprises’ expectation is how much business they can process in minimum possible time.  They are looking for a setup with minimum response time for output with maximum current and future workload capacity. In other words, these systems should process maximum business transactions in a day, an hour or a second with minimum response time. Many customers are not sure on how many business transactions they can process on day 1 and how much they want to process after 3 or 5 years. Also, they are not sure how many users (may be concurrent) are going to use this new system at present and after 3 or 5 years.
Ex: If any retail giant starts an e-commerce portal, they are not sure on day 1 how many users would log-in and how many transactions would go through the new system. They are also not sure about future workload. They can assume and calculate some numbers based on their initial study before they are getting on to the new system design. This brings us to another set of considerations that we must think of while designing the database system – Transactions Per Second (TPS), Response Time, Concurrent users etc.
From the above considerations, we can imagine the importance of looking into various aspects of highly available and scalable database design. A mere ‘Active-Active’ wordings doesn’t get you what you are looking for. Lastly, availability of budget drives how much resiliency you can build in your system.
Ashnik has expertise in High availability, Database Load Balancing, Application Load Balancing and performance improvement. Ashnik will help you to make sure that your application remains connected to databases for the present and the future workloads and makes sure that there is a solid business continuity even you face planned and unplanned outage situation.
Ashnik can design solutions to achieve minimum RPO and minimum RTO with required performance and most importantly, in a cost-effective manner.
Using Enterprise Open Source products for HA, Load Balancing and caching features, Ashnik consultant can help you to design a solution to achieve your real goal with less investment on the IT infrastructure cost. You really don’t need to depend upon expensive commercial ‘Appliances’.
So, ask Ashnik today, on how to achieve Active-Active in the most cost effective manner!
Ajit Gadge I Senior Database Consultant, Ashnik


Ajit brings over 16 years of solid experience in solution architecting and implementation. He has successfully delivered solutions on various database technologies including PostgreSQL, MySQL, SQLServer. His derives his strength from his passion for database technologies and love of pre-sales engagement with customers. Ajit has successfully engaged with customers from across the globe including South East Asia, USA and India. His commitment and ability to find solutions has earned him great respect from customers. Prior to Ashnik he has worked with EnterpriseDB for 7 years and helped it grow in South East Asia and India



Go to Top