Everyone wants high availability, and that’s completely understandable. When an app goes down, users get frustrated, business stops, and pressure builds.
But here’s the challenge: high availability often feels like a big monster. Many people think, If I need to set up high availability, I must master every tool involved. And there’s another common belief too: Open-source tools are not enough for real HA, so I must buy paid tools.
These assumptions make high availability seem far more complex than it really is, and in this series, we are going to address it.
This Is a 2-Part Series.
- Part 1 (this one): We will lay the foundation by answering the most important questions you should consider before going hands-on with HA systems.
- Part 2: We will go fully hands-on. I will walk through the architecture diagram, the tool stack, and provide the exact commands and step-by-step instructions to deploy the cluster based on your requirements.
The “Number of Nines”, RTO, and RPO
These are the foundations of a high-availability cluster. If you understand them and answer them clearly, you are already very close to building your HA setup.
Imagine you have a main site (your primary system). Things are working fine. Life is good. But one day, a disaster happens, maybe a server fails, a region goes down, or your database crashes.
At that moment, three questions decide everything.
1) How much downtime can you accept?
This is where the number of nines comes in (like 99.9% uptime, 99.99%, and so on). More nines usually mean less downtime, but also more effort and architectural cost.
Here’s a simple table to help you choose the right architecture based on your needs.
| Target uptime (“nines”) | Allowed downtime (per year) | A setup that usually fits | Notes / what you must be ready for |
| 99% | ~3.65 days | Single node + solid backups + tested restore | Backups and restore drills matter more than fancy tooling. |
| 99.9% | ~8.8 hours | 2-node setup + proper witness node (same region) | Witness helps avoid split-brain and supports clean failover decisions inside one region. |
| 99.99% | ~52.6 minutes | Multi-region (2 regions) | To reach 4 nines, you usually need to survive a full region failure, so you move beyond single-region design. |
| 99.999% | ~5.3 minutes | Active-active / multi-master style setup | This level is extremely hard. It often needs multi-master/active-active patterns and very mature operations; many teams use specialized (often paid) solutions. |
2) How fast do you want to recover?
RTO (Recovery Time Objective) is how long you are willing to wait before your system is back up after a failure.
If your RTO is 5 minutes, it means that when your main database crashes, your failover database must take over and be serving traffic within 5 minutes. If it takes 10 minutes, you have missed your RTO.
Important
One can confuse the number of nines with RTO because both relate to downtime, but they measure different things. A system can have high uptime, but a longer RTO:
Imagine a website is up 99.99% of the time, but if it crashes, it takes 30 minutes to recover. Most of the year, it’s available, but when it fails, recovery is slower.
Or a very short RTO but slightly lower uptime:
Now imagine a website might be up 99.9% of the time, but if it crashes, it recovers within 5 minutes. It goes down slightly more often, but when it does, users are back online quickly.
RTO should always fit within your number of nines target.
3) How much data loss can you tolerate?
RPO (Recovery Point Objective) is how much data you can afford to lose if things go wrong.
In simple words: “If we go back in time, how far back is acceptable?”
If your RPO is 30 seconds, it means that in a failure, the most data you can afford to lose is the last 30 seconds of transactions.
Once You Answer These, The Path Becomes Clear
Then you can choose an architecture that matches your needs, based on:
- Your downtime limit
- Your recovery time and your data loss tolerance.
The main takeaway from this first part is that you don’t need to be an expert to start. What matters is asking the right questions and understanding your business’s operational needs.
What’s Coming in Part 2
In Part 2, we will deploy an architecture that delivers near-zero RTO and RPO with 99.99% high availability, all without requiring deep technical expertise. and with open-source tools only.