In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.
👋 👋 A big thank you to today's sponsor WISPR FLOW
Your AI prompts are leaving out 80% of what you're thinking.
When you type a prompt, you summarize. When you speak one, you explain. Wispr Flow captures your full reasoning (constraints, edge cases, examples, tone) and turns it into clean, structured text you paste into ChatGPT, Claude, or any AI tool. The difference shows up immediately. More context in, fewer follow-ups out.
Used by teams at Microsoft, Amazon, and Notion. Try Wispr Flow free on Mac, Windows, iPhone, and Android.
👀 Remote Jobs
Colonist is hiring a DevOps Engineer
Remote Location: Worldwide
Mode is hiring a DevOps / Network Engineer (VPN)
Remote Location: Worldwide
📚 Resources
Looking to promote your company, product, service, or event to 50,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
AWS Fault Tolerance and High Resilience Architecture Explained
More often than not I see too many cloud engineers especially the beginners get confused between Fault Tolerance and High Availability. Once for all..
Fault tolerance means the system continues to operate even when a part of it dies. For example, if one Availability Zone in AWS goes completely dark, a fault tolerant design will have another zone already running the same workload without any disruption.
High availability means the system remains accessible most of the time with very little downtime. For example, if an EC2 instance in a zone crashes, Auto Scaling launches a new one and the service is restored within minutes.
Load balancing ties both together by continuously distributing traffic across multiple servers and rerouting users away from unhealthy ones, keeping the service both available and fault resilient.
How Availability gets calculated in real ?
Total availability is calculated by multiplying the uptime of each tier in the system. This is where design choices directly change the final percentage, eventually hits your target SLA.
When a single tier is in use like one web server, one app server, and one database, the overall uptime quickly drops. Each server may run 99% on its own, but once you stack them together the effective uptime is much lower than expected.
When you add redundancy in the web tier with two servers behind a load balancer, that tier’s uptime improves dramatically. This raises the overall system uptime as well.
When you extend the same design to every tier with multiple web servers, multiple app servers, and a master–replica database, the compounded uptime gets close to the high availability targets most businesses set in their SLAs.
It is no wonder in all the three examples though the individual tier element availability numbers are the same, the total availability dramatically improves from 96.04% to 99.4%.
Take away:
Redundancy in a single tier lifts the entire system.
Overall uptime depends on how tiers are combined.
End to end redundancy across all tiers delivers near SLA grade uptime.
With this foundation knowledge on high availability, let us deep dive into practical AWS architecture and the nuances that make it work in the real world.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 200+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
