Two Data Centers. One Storm. Zero Excuses.

The Deployment Strategy That Decides Whether Your IROPS App Survives or Collapses.

It was 7:40 PM. Thunderstorms over Delhi. Flights stacking. Crew legality breaking. Connections collapsing.

Our IROPS (Irregular Operations) app wasn’t just serving APIs. It was deciding which passenger gets reprotected, which crew times out, and which aircraft gets reassigned.

In IROPS, downtime is not a “minor incident.” It’s operational chaos.

That night forced us to answer three uncomfortable questions:

1. Active-Active or Active-Passive?
2. How do we roll changes without breaking the system mid-crisis?
3. If Active-Active fails, what’s our escape hatch?

Let’s break this down

Active-Active vs Active-Passive — The Real Tradeoff

🔵 Active-Active Architecture

Definition: Both regions serve live traffic simultaneously. Traffic is distributed via global load balancer (GeoDNS, Traffic Manager, Global Accelerator).

Pros

• Zero theoretical downtime (if designed correctly)
• Better latency (users routed to nearest region)
• Horizontal scalability during spikes
• True disaster resilience

Cons

• Data consistency complexity (eventual vs strong consistency)
• Conflict resolution logic required
• Stateful session handling becomes non-trivial
• Split-brain risk during partial outages
• Higher infra cost

In IROPS, where decisions are state-heavy (PNR changes, crew swaps, aircraft reassignment), distributed write conflicts can become a nightmare.

Active-Passive Architecture

Definition: One region actively serves traffic. The other stays warm (or hot standby) and takes over during failure.

Pros

• Simpler data consistency model
• Single write authority
• Easier debugging
• Lower operational complexity
• Cheaper

Cons

• Failover time (seconds to minutes)
• Cold start risk if not warm
• Slightly lower availability vs perfect Active-Active

For IROPS Apps — What’s Preferred?

For airline IROPS systems, the preferred strategy is:

Active-Passive for core transactional services

- Active-Active for read-heavy services

Why?

IROPS involves:

• PNR modifications
• Crew legality updates
• Aircraft tail reassignments
• Rebooking orchestration
• Payment adjustments

These are write-heavy and state-sensitive workflows.

Conflict resolution during a storm is the last thing you want to debug.

So the real-world hybrid looks like this:

That’s how mature aviation stacks are built.

Rolling Deployments Using GitHub Actions

Now let’s talk about not breaking prod during a storm.

A rolling deployment updates pods gradually without downtime.

Kubernetes Rolling Strategy

strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0

This ensures:

• One extra pod spins up
• Zero pods go down until new one is healthy

GitHub Actions Workflow Example

name: Deploy IROPS Service
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Build Docker Image
run: docker build -t irops-app:${{ github.sha }} .
- name: Push to Registry
run: docker push irops-app:${{ github.sha }}
- name: Deploy to K8s
run: |
kubectl set image deployment/irops-app \
irops-container=irops-app:${{ github.sha }}

Rolling deployments depend on:

• Readiness probes
• Liveness probes
• Proper resource limits
• Circuit breakers (Resilience4j / Spring Cloud)

In IROPS, your readiness probe must validate:

• DB connectivity
• Cache health
• Kafka connectivity (if event-driven)

Because “Pod is running” ≠ “Service is safe to route traffic.”

What If Active-Active Goes Wrong?

And it will. Eventually.

Common failure modes:

• Partial regional degradation
• Replication lag
• Schema mismatch
• Cache inconsistency
• Message duplication

Fallback Strategy for Active-Active

1️⃣ Global Traffic Shift

Use DNS / Traffic Manager to route 100% traffic to stable region.

Time to execute: < 2–5 minutes (depending on TTL).

2️⃣ Circuit Break Write Operations

Temporarily:

• Route writes to single region
• Convert second region to read-only

This avoids split-brain.

3️⃣ Feature Flag Kill Switch

Critical flows (re-accommodation automation) should be feature-flag controlled.

Disable automation. Fallback to manual ops dashboard.

4️⃣ Database Authority Override

If dual-write fails:

• Designate one DB as source of truth
• Stop cross-region replication
• Run reconciliation job

5️⃣ Blue-Green Recovery

If deployment caused issue:

• Keep previous version warm
• Switch traffic back immediately

Rolling update rollback:

kubectl rollout undo deployment/irops-app

Rollback time: seconds.

Hard Truth

Active-Active increases availability. But it multiplies operational complexity.

Active-Passive reduces complexity. But slightly increases RTO.

For IROPS, availability without consistency is dangerous.

You need:

• Strong write discipline
• Clear failover playbook
• Observability across regions
• Chaos testing drills
• Controlled rollout strategy

Because in aviation:

Passengers don’t see your architecture. They only see delay screens.

And your deployment strategy decides whether that screen shows chaos… or recovery.