DEV Community: Ankur

Your Load Balancer Is a Single Point of Failure. Fix It With VRRP

Ankur — Fri, 11 Sep 2026 06:20:04 +0000

You built the system the way everyone tells you to.

Three API servers instead of one, so a crash doesn't take you down. A load balancer in front of them spreading traffic around. Your domain points at the load balancer, the load balancer health-checks the backends, and when one server dies the other two pick up the slack. Textbook.

Then at 2 AM the load balancer itself dies.

Not a backend. The balancer. Maybe the box lost power, maybe the kernel panicked, maybe HAProxy hit an out-of-memory kill. It doesn't matter which. Your three API servers are sitting there completely healthy, idle, ready to serve, and every single request is timing out. Because nothing can reach them anymore.

You removed the single point of failure from your application tier and quietly moved it to the thing in front.

Adding a second load balancer doesn't fix it

The instinct is right: run two.

The problem is what clients are actually dialling. Your DNS points api.example.com at 203.0.113.10, and that address belongs to load balancer 1. Load balancer 2 sits there with 203.0.113.11, perfectly healthy, and no traffic at all. Nobody is asking for it.

So you update DNS to point at the second one. Now you wait. TTLs are cached by resolvers, by operating systems, by browsers, and some of them ignore your TTL entirely. You're looking at minutes of downtime at best, and a long tail of clients still hammering the dead address. That's not failover, that's a slow-motion recovery.

What you actually need is for the address to move. Clients keep dialling 203.0.113.10, and a different machine starts answering for it. No DNS change, nothing to wait for.

That's what a virtual IP is, and VRRP is how two machines agree on who's currently answering.

What is a virtual IP address?

A virtual IP (VIP) is an address that no machine owns permanently.

Clients connect to it, DNS points at it, firewall rules reference it. But it can move from one server to another without anything on the client side changing. The address stays fixed while the hardware behind it is replaced, scaled, or fails.

You're already using one whether you call it that or not. api.example.com resolving to 203.0.113.10 with three backends behind it on private addresses is a VIP in front of a pool. Clients never learn a backend address, so you can add or remove servers freely.

Virtual IP address load balancing: the front door

A client opens a TCP connection to 203.0.113.10. The load balancer accepts it and picks a backend, say 10.0.1.6. How the packet gets there depends on the mode:

Proxy mode (ALB, nginx, HAProxy): the balancer terminates the client connection and opens a separate one to the backend. Two TCP connections. The backend sees the balancer's IP as the source, which is why X-Forwarded-For exists.
NAT or direct server return (LVS, classic L4 balancers): the balancer rewrites the destination and forwards the packet. The backend replies straight to the client. Faster, but the backend has to be configured to accept traffic addressed to the VIP.

Either way, the client only ever talks to the VIP. Now we need that VIP to survive the balancer holding it.

What is VRRP?

VRRP stands for Virtual Router Redundancy Protocol. Defined in RFC 5798, it's the protocol that lets several machines agree on who currently owns a virtual IP, and elect a replacement when that owner disappears.

It was designed for redundant routers, but it's used for anything that needs a floating address: load balancers, firewalls, database proxies, NFS heads.

How does VRRP work?

Two or more nodes are configured with the same virtual IP and a shared group ID (the VRID). Each node gets a priority number.

Election. The highest-priority node becomes the master. It is the only node that claims the VIP and answers for it. Everyone else is a backup and stays completely silent. Two machines answering for one address would be a disaster, so silence is the default state.

Heartbeat. The master multicasts small advertisement packets to 224.0.0.18, by default once per second. This is the "I'm alive" signal. VRRP runs directly over IP as protocol number 112, not TCP or UDP, so there's no port to open — your firewall rule has to allow the protocol itself.

Failover. Backups listen for those advertisements. If roughly three intervals pass with silence, they conclude the master is gone, hold an election by priority, and the winner claims the VIP. Typical failover lands in the 1–3 second range.

VRRP priority: higher or lower?

Higher wins. The range is 1–254, the default is 100, and 255 is reserved for the node that owns the IP as a real interface address. Give your intended master 100 and the standby 90.

Preempt controls what happens when a recovered node with higher priority comes back. With preemption on (the default), it takes the VIP back immediately. Turning it off is often wiser: it avoids a second disruption, and it stops a flapping node from bouncing traffic back and forth every time it recovers.

The VRRP MAC address

VRRP doesn't just move an IP. The group also gets a virtual MAC address, formatted 00:00:5E:00:01:XX, where XX is the VRID.

This matters more than it sounds. Because the MAC moves with the IP, some switches don't need to relearn anything at all during a failover — the address pair is identical, only the physical port changes.

Where ARP fits in

VRRP decides who owns the VIP. ARP is how the rest of the network finds out.

ARP (Address Resolution Protocol) is the lookup that maps an IP address to a hardware MAC address on the local network. When a machine wants to send to 203.0.113.10, it broadcasts "who has this address?" and caches the answer for a few minutes.

That cache is the problem during failover. Neighbours are still holding a mapping that points at a dead machine, and waiting for it to expire would mean minutes of downtime.

So the new master sends a gratuitous ARP: an unsolicited broadcast announcing "203.0.113.10 is at my MAC." Nobody asked. Every device on the segment overwrites its cached entry immediately, and switches update their MAC tables. That single broadcast is what makes VIP failover take seconds instead of minutes.

This is also why VIP failover beats DNS failover. No TTL to wait out, no client-side DNS caching to fight.

Setting it up with keepalived

On Linux, keepalived is the standard VRRP implementation. A minimal config:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51      # same VRID on both nodes
    priority 100              # 90 on the standby
    advert_int 1              # heartbeat interval, seconds
    authentication {
        auth_type PASS
        auth_pass changeme
    }
    virtual_ipaddress {
        203.0.113.10
    }
}

That config only fails over when the whole box dies. If HAProxy crashes but the server stays up, the master keeps the VIP and serves nothing. Add a health check so the node drops its own priority when the service is unhealthy:

vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight -20               # drops priority below the standby
}

Then reference it with track_script { check_haproxy } inside the instance block.

Split-brain: the failure mode to plan for

If the heartbeat path breaks but both nodes are alive and healthy, each concludes the other is dead. Both claim the VIP. The ARP table flaps between two MACs, and traffic splits unpredictably between two machines that both think they're in charge.

Mitigations: run the heartbeat over a dedicated link or more than one path, use VRRP authentication so stray packets can't interfere, and add an external check so a node can tell "the peer is down" apart from "I am isolated."

VRRP vs HSRP

Both solve the same problem. The differences that matter:

	VRRP	HSRP
Standard	Open, RFC 5798	Cisco proprietary
Terminology	Master / backup	Active / standby
Default timer	1 second	3 seconds
Virtual IP	Can be a real interface IP	Must be separate
Multicast	224.0.0.18	224.0.0.2

In a mixed-vendor environment, VRRP is the only real option. In an all-Cisco shop it's mostly preference, though VRRP's faster default timers give it an edge on failover speed.

What this looks like in the cloud

If you're on AWS or GCP, you probably won't configure VRRP by hand. An ALB or NLB hands you a DNS name and runs multiple nodes across availability zones, handling all of this internally. That's why the docs insist you point at the DNS name and never hardcode the resolved IP.

Kubernetes does the same trick at a different layer: a ClusterIP Service is a virtual address that exists only in iptables or IPVS rules, with kube-proxy rewriting the destination to a real pod IP.

VRRP still shows up in self-managed clusters, on-prem load balancers, bare-metal Kubernetes with kube-vip or MetalLB, and anywhere you run HAProxy or nginx yourself.

One thing to handle in your application

Failover is fast, but it isn't transparent. Every TCP connection through the old master is gone, including your database connection pools.

Your app will hold sockets that look open and are actually dead. So validate connections on checkout, set aggressive TCP keepalives, and retry idempotent operations once. And keep session state in Redis rather than in the load balancer's memory, because sticky sessions held on the failed node don't come back.

The short version

A virtual IP is an address that isn't tied to a machine. VRRP is how machines agree on who currently holds it. Gratuitous ARP is how the rest of the network finds out within seconds.

Between them, the address your clients depend on outlives any single server that ever answers for it.

Autonomous AI Agents: Give It a Goal, Not a Script

Ankur — Tue, 08 Sep 2026 12:07:26 +0000

Most AI tools wait for you. You type, they answer, they stop.

An autonomous AI agent does not stop. You give it a goal, and it keeps working until the goal is done. It decides the steps by itself.

That is the whole difference. Everything else is detail.

What are autonomous AI agents?

An autonomous AI agent is software that takes a goal, makes its own plan, uses tools to do the work, checks the result, and fixes its own mistakes.

Simple example.

You tell a normal chatbot: "Write an email to this customer." It writes one email. Done.

You tell an agent: "Follow up with every customer who did not reply last week." The agent pulls the list, checks who replied, writes an email for each person, sends them, and logs it. You did not tell it any of those steps. It worked them out.

What makes an agent autonomous?

Four things. If a tool is missing any of them, it is not really an agent.

1. A goal, not a script

You give the outcome you want. Not the steps. "Get this bug fixed" instead of "open file A, change line 30."

2. It picks its own next step

After every action, the agent decides what to do next based on what just happened. Nobody wrote that decision in advance.

3. It can use tools

An agent that can only talk is useless. A real agent can search the web, read a database, send an email, run code, or update a CRM record. Tools are how it touches the real world.

4. It checks its own work

The agent looks at the result, sees if it worked, and tries again if it did not. This is the part most fake agents skip.

The planning loop, explained simply

People call this the sense, think, act cycle. It runs in a loop until the job is done.

Step	What happens
Sense	The agent looks at the current situation. What has it done so far? What came back?
Think	It decides the single next action that moves it closer to the goal.
Act	It uses a tool. Runs the code, sends the message, reads the file.
Check	It reads the result. Did it work? If not, why not?

Then the loop starts again with new information.

Say the goal is "fix the login bug."

Loop 1: Read the error log. Loop 2: Find the file causing it. Loop 3: Change the code. Loop 4: Run the tests. Tests fail. Loop 5: Read why they failed, change the code again. Loop 6: Tests pass. Stop.

Six steps, no human in between. That is a planning loop.

Two things keep the loop from going wrong. Memory, so the agent remembers what it already tried and does not repeat it. And a stop rule, like a step limit or a cost limit, so it does not run forever on an impossible task.

Autonomous agents vs workflow automation

This is the question most people get wrong.

	Workflow automation	Autonomous agent
Steps	Fixed, written by a human	Decided at runtime
New situation	Breaks	Adapts
Failure	Stops and alerts you	Tries another way
Best for	Repeating the same task	Tasks that change every time
Cost	Cheap and predictable	Higher and varies

Zapier moving a form entry into a spreadsheet is automation. The steps never change.

An agent reading 200 support tickets, grouping them by problem, and writing a summary is agent work. Every ticket is different, so the steps cannot be written in advance.

Automation is not worse. It is just for different jobs. If your task never changes, do not use an agent. You will pay more for the same result.

A note on "agentic AI": people use the two terms almost the same way. Agentic AI is the broader idea of AI that acts. An autonomous agent is one system built on that idea.

Real deployments that work today

Here is where agents are already earning their cost.

Coding. Agents like Claude Code and similar tools take a task, read the codebase, write the change, run the tests, and fix what breaks. This is the strongest use case right now because tests give the agent clear feedback on whether it succeeded.

Customer support. Agents read the ticket, look up the customer's order and history, answer simple questions, and pass hard ones to a human. Companies usually keep a human approving anything involving refunds or account changes.

Sales and CRM. Agents research a lead, find recent company news, write a personal first email, and update the CRM after. Salesforce, Microsoft, and Oracle all sell this now.

Security. Agents scan alerts, throw out the false alarms, and flag real threats for the team. Security teams get thousands of alerts a day, so filtering is a perfect agent job.

Operations and reporting. Agents pull numbers from several systems, spot what changed, and write the weekly report.

Notice the pattern. Every one of these has a clear goal, tools the agent can use, and a way to check if the work was right.

Where autonomous agents still fail

Be honest about this before you spend money.

They get stuck in loops. An agent can try the same failing approach ten times. You need step limits.
Costs jump around. One task might take 5 steps, another 50. Budget for the bad case.
Mistakes multiply. If each step is 95% right, ten steps in a row are only about 60% right overall. Long tasks are risky.
Wide access is dangerous. An agent with permission to send emails or change records can do real damage fast. Give it the smallest permissions that work.
Fuzzy goals produce fuzzy work. If a human cannot tell whether the task is done, the agent cannot either.

How to start

Pick one task where the answer is clearly right or wrong. Test coverage, ticket sorting, data checks. Something you can grade.

Keep a human approving the final action for the first few weeks. Watch what the agent tried, not just what it produced. Set a hard step limit and a cost cap from day one.

Then widen it once you trust the logs.

Common questions

How do autonomous AI agents work?
They run a loop. Look at the situation, choose one action, do it with a tool, check the result, repeat until the goal is met or a limit is hit.

Are AI agents and chatbots the same?
No. A chatbot replies once. An agent keeps working across many steps and uses tools to do real actions.

Do I need to code to build one?
Not always. Copilot Studio and similar platforms let you build agents with a visual editor. Custom agents usually use frameworks like LangGraph and need Python or JavaScript.

Can an agent run with no human at all?
Technically yes. In practice most teams keep a human approving anything that spends money, sends messages, or deletes data.

The short version

An agent is autonomous when it gets a goal instead of steps, decides its own next move, uses real tools, and checks its own work.

The loop is simple: look, decide, act, check, repeat.

Start with one task you can grade. Let the agent prove itself there before you hand it anything bigger.

System Design Life Cycle: 7 Stages Explained With Diagrams

Ankur — Fri, 04 Sep 2026 12:53:48 +0000

Every system you rely on, from your banking app to the checkout page you used this morning, went through the same journey: someone identified a need, shaped it into requirements, designed a solution, built it, tested it, shipped it, and now keeps it alive. That journey has a name: the system design life cycle, more formally known as the System Development Life Cycle (SDLC).

Most explanations of the SDLC stop at listing the stages. This one walks through the entire cycle the way it actually plays out on a project: what happens at each stage, what goes in, what comes out, who is involved, and where teams most often get it wrong.

What Is the System Design Life Cycle?

The system design life cycle is a structured process for building information systems, taking them from an initial idea to a deployed, maintained product. It breaks the work into distinct stages, each with defined inputs, activities, and deliverables, so that large, risky projects become a sequence of smaller, verifiable steps.

Here is the whole cycle at a glance:

flowchart TD
    A[1. Planning] --> B[2. Feasibility Study]
    B --> C[3. Requirements Analysis]
    C --> D[4. System Design]
    D --> E[5. Development]
    E --> F[6. Testing]
    F --> G[7. Deployment & Maintenance]
    G -->|feedback and new requirements| A

Notice the loop at the end. The life cycle is a cycle, not a straight line. Feedback from a live system feeds the planning of its next version, which is why systems evolve in versions rather than being built once and left alone.

Why does this structure matter? Because the cost of fixing a mistake grows dramatically the later you catch it. A requirements misunderstanding caught during analysis costs a conversation. The same misunderstanding caught in production costs a re-architecture. The SDLC exists to catch problems at the stage where they are cheapest to fix.

The 7 Stages of the System Design Life Cycle

Let's walk through each stage in order, using a running example: a mid-size retailer building an inventory management system to replace spreadsheets.

Stage 1: Planning

Planning answers one question: what problem are we solving, and is it worth solving?

At this stage nobody is writing code or drawing architecture diagrams. The work is about scope and alignment:

Define the problem statement ("stock counts are wrong 15% of the time, causing lost sales")
Identify stakeholders: who owns the problem, who uses the system, who pays for it
Set high-level goals and success metrics
Estimate budget, timeline, and required team
Identify major risks early

Input: a business need. Output: a project plan and charter that gives the team permission and direction to proceed.

The most common failure here is skipping it. Teams that jump straight to building tend to produce technically sound systems that solve the wrong problem.

Stage 2: Feasibility Study

Before committing serious money, you check whether the project can actually succeed. A feasibility study examines the idea from four angles:

Feasibility Type	Question It Answers
Technical	Can we build this with available technology and skills?
Economic	Do the benefits justify the cost?
Operational	Will the organization actually use it?
Schedule	Can it be delivered in a useful timeframe?

For our retailer: barcode scanners and a web dashboard are technically routine, the cost is recovered in under a year of reduced stock errors, and warehouse staff are asking for the tool. Green light on all four.

Output: a feasibility report with a go/no-go recommendation. A "no-go" here is a success, not a failure. It just saved the organization from a much more expensive lesson.

Stage 3: Requirements Analysis

This is where vague goals become precise, testable statements. Analysts gather requirements through stakeholder interviews, observation of current workflows, questionnaires, and analysis of existing systems, then split them into two categories:

Functional requirements: what the system must do. "The system shall update stock counts within 2 seconds of a barcode scan."
Non-functional requirements: how well it must do it. Performance, security, availability, scalability. "The system shall support 200 concurrent warehouse users with p95 latency under 500ms."

The deliverable is a Software Requirements Specification (SRS): the contract that every later stage is measured against. Test cases in Stage 6 will trace directly back to lines in this document.

The classic pitfall: writing requirements as solutions ("use PostgreSQL") instead of needs ("stock data must survive a server crash without loss"). Requirements say what; design decides how.

Stage 4: System Design

Now the "how" begins. Design happens at two levels of zoom:

High-Level Design (HLD) defines the architecture: the major components, how they communicate, and the technology choices. For the inventory system:

flowchart LR
    subgraph Clients
        S[Scanner App]
        W[Web Dashboard]
    end
    S --> G[API Gateway]
    W --> G
    G --> I[Inventory Service]
    G --> R[Reporting Service]
    I --> D[(Inventory DB)]
    R --> D
    I --> Q[[Event Queue]]
    Q --> N[Notification Service]

Low-Level Design (LLD) zooms into each component: database schemas, API contracts, class structures, algorithms, and error handling. This is where "Inventory Service" becomes concrete tables, endpoints, and validation rules.

Typical design deliverables include:

Architecture diagrams (like the one above)
Data flow diagrams (DFDs) and entity-relationship diagrams (ERDs)
API specifications
UI wireframes and mockups
A design document recording decisions and the reasons behind them

That last point deserves emphasis. Recording why you chose an event queue over direct calls is what saves the next engineer from undoing a deliberate trade-off. Design is the art of choosing which problems you would rather have.

Stage 5: Development

With designs approved, developers implement the system. Because the thinking happened in earlier stages, this phase is more predictable than outsiders expect. The work follows the LLD, and modern teams layer in practices that keep quality high while code is being written:

Version control (Git) with code review on every change
Coding standards and linting
Unit tests written alongside the code
Continuous integration that builds and tests every commit

Input: design documents. Output: working, reviewed, unit-tested code.

The pitfall at this stage is silent drift: developers hitting a snag, quietly deviating from the design, and never updating the document. Small undocumented deviations compound into a system nobody fully understands.

Stage 6: Testing

Testing verifies the system against the SRS from Stage 3. It proceeds in expanding circles, often visualized as the V-model, where each test level validates a corresponding earlier stage:

flowchart TD
    U[Unit Testing<br/>individual functions] --> IN[Integration Testing<br/>components together]
    IN --> SY[System Testing<br/>the whole system vs. the SRS]
    SY --> UA[User Acceptance Testing<br/>real users, real workflows]

Unit testing checks individual functions against the low-level design.
Integration testing checks that components talk to each other correctly, exactly where the high-level design boundaries are.
System testing checks the entire system against the requirements, including non-functional ones (load tests for that 200-concurrent-user requirement).
User acceptance testing (UAT) puts the system in front of actual warehouse staff. They will find issues no engineer anticipated, like gloves making the scanner app's small buttons unusable.

Bugs found here loop back to development. The cycle repeats until the system meets its acceptance criteria.

Stage 7: Deployment and Maintenance

The system goes live, and how it goes live is itself a design decision:

Deployment Strategy	How It Works	Best For
Big bang	Everyone switches at once	Small systems, hard cutover dates
Phased	Roll out by region or module	Reducing risk on large user bases
Pilot	One group uses it first	Validating with real usage cheaply
Parallel	Old and new run side by side	Systems where errors are unacceptable

Our retailer runs a pilot in one warehouse, fixes what surfaces, then does a phased rollout.

Then comes the longest stage of the entire life cycle: maintenance. Studies consistently attribute 60 to 70% of a system's total lifetime cost to what happens after launch. Maintenance takes four forms: corrective (fixing bugs), adaptive (new OS versions, new regulations), perfective (improvements users request), and preventive (refactoring before things break).

And when users request enough changes, those requests become the input to a new planning stage. The cycle begins again.

SDLC Models: Different Paths Through the Same Stages

The stages above are universal, but how you move through them varies. That's what SDLC models define:

Model	How It Moves Through the Stages	Best Suited For
Waterfall	Strictly sequential, each stage completes before the next	Stable, well-understood requirements
V-Model	Waterfall with a test level paired to every stage	Safety-critical systems
Iterative	Repeated mini-cycles, each producing a better version	Requirements that clarify over time
Spiral	Iterations driven by explicit risk analysis	Large, high-risk projects
Agile	Small increments of every stage in short sprints	Fast-moving products with evolving needs
DevOps	Agile plus automated deployment and continuous feedback	Cloud products shipping frequently

A useful way to think about it: Waterfall walks the diagram top to bottom once; Agile runs a miniature version of the whole diagram every two weeks. Neither skips stages. Even a two-week sprint contains planning, analysis, design, development, testing, and deployment in compressed form.

Choosing a model comes down to two questions: how stable are your requirements, and how expensive is a mistake in production? Stable requirements and expensive mistakes push you toward sequential models; shifting requirements and cheap rollbacks push you toward iterative ones.

Best Practices Across the Life Cycle

Regardless of model, the teams that ship successful systems tend to share habits:

Involve users early and continuously. Most failed systems failed at requirements, not engineering.
Make deliverables traceable. Every test maps to a requirement; every requirement maps to a business goal.
Document decisions, not just outcomes. The "why" is what future maintainers need most.
Automate the repeatable. Builds, tests, and deployments done by hand eventually get done wrong.
Plan for maintenance from day one. The system will spend 90% of its life in Stage 7. Design like it.

Frequently Asked Questions

How many stages are in the system design life cycle?
Most sources describe 5 to 7 stages. The count varies because some merge planning with feasibility, or deployment with maintenance. The underlying activities are the same; only the grouping differs.

Is the system design life cycle the same as SDLC?
Effectively yes. SDLC stands for System (or Software) Development Life Cycle, and "system design life cycle" is a common way of referring to the same process, with emphasis on the design-centric middle stages.

Which SDLC stage is the most important?
Requirements analysis, by impact. Errors introduced there propagate through design, development, and testing, and they are the most expensive class of defect to fix late.

Which SDLC model should a beginner learn first?
Waterfall, because it presents each stage in its cleanest form. Then Agile, because it is what most modern teams practice day to day.

Wrapping Up

The system design life cycle is the map every serious software project follows, knowingly or not: plan, validate feasibility, pin down requirements, design at high and low levels, build, test in expanding circles, deploy deliberately, and maintain for the long haul. The stages don't exist for bureaucracy. Each one is a checkpoint that catches a class of mistakes while they're still cheap.

If you take one thing from this walkthrough, make it this: the cycle loops. Systems are never finished, only released. The best teams treat the feedback arrow from maintenance back to planning not as a failure mode but as the whole point.

DEV Community: Ankur

Your Load Balancer Is a Single Point of Failure. Fix It With VRRP

Adding a second load balancer doesn't fix it

What is a virtual IP address?

Virtual IP address load balancing: the front door

What is VRRP?

How does VRRP work?

VRRP priority: higher or lower?

The VRRP MAC address

Where ARP fits in

Setting it up with keepalived

Split-brain: the failure mode to plan for

VRRP vs HSRP

What this looks like in the cloud

One thing to handle in your application

The short version

Autonomous AI Agents: Give It a Goal, Not a Script

What are autonomous AI agents?

What makes an agent autonomous?

The planning loop, explained simply

Autonomous agents vs workflow automation

Real deployments that work today

Where autonomous agents still fail

How to start

Common questions

The short version

System Design Life Cycle: 7 Stages Explained With Diagrams

Table of Contents

What Is the System Design Life Cycle?

The 7 Stages of the System Design Life Cycle

Stage 1: Planning

Stage 2: Feasibility Study

Stage 3: Requirements Analysis

Stage 4: System Design

Stage 5: Development

Stage 6: Testing

Stage 7: Deployment and Maintenance

SDLC Models: Different Paths Through the Same Stages

Best Practices Across the Life Cycle

Frequently Asked Questions

Wrapping Up

References