Migrating from Cloud to Bare Metal: Dukaan’s Architecture and Infrastructure Blueprint

Public cloud providers like AWS, Google Cloud Platform (GCP), and Microsoft Azure are universally treated as the default infrastructure choice for modern tech companies. However, as an engineering organization scales, cloud bills often grow exponentially while virtualization and multi-tenant abstractions introduce subtle performance and I/O bottlenecks.

E-commerce enablement platform Dukaan undertook a counterintuitive engineering journey: fully migrating their core production workloads from hyperscale cloud providers onto self-hosted bare-metal servers. This breakdown explores the technical mechanics, economic incentives, operational pipelines, and disaster recovery strategies behind their move.

---

1. The Scaling Path and the Cloud Bill Problem

Dukaan was founded during the COVID-19 pandemic to enable local merchants to set up digital storefronts directly from mobile devices. The product went viral almost immediately:

• Initial Prototype: Bootstrapped on a single $5/month DigitalOcean droplet (application and database co-located).
• Hypergrowth: Achieved over 1 million mobile app downloads and hundreds of thousands of active storefronts within weeks.
• Migration to AWS: After raising venture capital, the company leveraged standard startup credits ($50,000–$60,000) and re-architected on AWS.
• The Bill Shock: As the platform scaled, the monthly cloud expenditure reached $80,000–$90,000 per month.

When evaluating cloud cost-optimization paths, provider sales teams typically suggest:

1. Moving mission-critical production workloads to Spot/Preemptible instances (introducing significant availability risks).
2. Signing 3-year Reserved Instance / Savings Plan commitments totaling millions of dollars upfront.

Given that hardware reliability has drastically improved over the last decade, Dukaan chose a third route: migrating core workloads to dedicated bare-metal servers.

---

2. Bare Metal vs. Cloud: The Hardware & I/O Equation

A primary technical driver for moving off public cloud was Disk I/O latency.

The Multi-Tenant Cloud Storage Tax

When running a relational database on managed cloud services (such as AWS RDS or GCP Cloud SQL) using virtual block devices (such as AWS EBS):

• Storage volumes are network-attached, distributed block stores.
• Every disk write must be synchronously replicated across multiple independent physical servers, network switches, racks, and availability zones to guard against hardware degradation.
• This distributed consensus layer provides high durability, but introduces significant network latency and IOPS limits on transactional database operations.

+-------------------------------------------------------------------------+
|                        Cloud Database Write Path                         |
|                                                                         |
|  [Application] ---> [Virtual Machine (EC2)]                             |
|                              | (Network Hop)                            |
|                              v                                          |
|                     [Virtual EBS Driver]                                |
|                              | (Network Distributed Fabric)             |
|             +----------------+----------------+                         |
|             v                                 v                         |
|   [Storage Node 1 (AZ-a)]           [Storage Node 2 (AZ-b)]             |
+-------------------------------------------------------------------------+

+-------------------------------------------------------------------------+
|                     Bare-Metal Direct Write Path                        |
|                                                                         |
|  [Application] ---> [Bare-Metal Server OS]                              |
|                              | (Direct PCIe Bus)                        |
|                              v                                          |
|                    [NVMe Direct Storage]                                |
+-------------------------------------------------------------------------+

The Bare-Metal NVMe Advantage

On dedicated bare metal, database instances read and write directly to enterprise-grade NVMe SSDs connected to the motherboard via high-speed PCIe lanes:

• Zero Network Hops for Local I/O: Transaction logs (WAL) flush to disk with sub-millisecond latencies.
• CPU & Memory Predictability: Zero noisy-neighbor problems, no hypervisor CPU scheduling stealing cycles, and no throttled burst credits.
• Hardware Reliability: Modern enterprise NVMe drives in RAID configurations exhibit negligible failure rates compared to historical spinning magnetic disks.

---

3. Dukaan’s Production Architecture

Dukaan runs a microservices-based backend using an open-source, vendor-agnostic software stack to avoid proprietary cloud lock-in.

graph TD
    Client([B2B / B2C Clients]) --> CDN[Global CDN / Cloudflare]
    CDN --> Ingress[Edge Ingress / Reverse Proxy]
    
    subgraph Bare_Metal_Kubernetes_Cluster [Bare-Metal K8s Fleet]
        Ingress --> Auth[Auth Service - Optimus]
        Ingress --> StoreFront[Storefront Service]
        Ingress --> OrderAPI[Order Service - Buyer & Seller APIs]
        Ingress --> Payments[Payment Service]
        Ingress --> Search[Search Service]
        Ingress --> SSE[Server-Side Events]
        
        OrderAPI --> RabbitMQ[(RabbitMQ Queue)]
        Payments --> RabbitMQ
        
        RabbitMQ --> HighPriWorker[High Priority Workers: OTPs, Order Alerts]
        RabbitMQ --> LowPriWorker[Low Priority Workers: Marketing, Third-party Sync]
        
        Auth --> LocalPG[(Primary PostgreSQL - Bare Metal NVMe)]
        OrderAPI --> LocalPG
        Payments --> LocalPG
    end
    
    subgraph Cloud_Disaster_Recovery [Cloud Standby - GCP/AWS]
        LocalPG -.->|Real-time Streaming Replication| CloudReplica[(Standby Read Replica)]
        LocalPG -.->|WAL / PITR Logs| CloudStorage[(Object Storage - GCS/S3)]
        DREngine[Cold K8s Manifests Ready on Git]
    end

Core Workloads & Subsystems

• Optimus (Auth Service): Handles identity, authorization tokens, and session management.
• Order Engine: Separated into two distinct operational flows:
  • Buyer-side API: Latency-sensitive checkout and cart interactions.
  • Seller-side API: Store management, catalog updates, and order processing.
• Payments Service: Connects to payment gateways (Razorpay, Cashfree, Stripe) and abstracts external webhooks into standardized internal platform events.
• Background Processing: Python/Celery running workers against RabbitMQ, separated into queue tiers:
  • High-Priority: Real-time user communications (SMS OTPs, push notifications, payment settlement confirmations).
  • Low-Priority: Periodic third-party logistics polling (e.g., querying carrier tracking APIs) and scheduled marketing broadcasts.
• Server-Side Events (SSE): Ingestion pipelines capturing clickstream and behavioral data for millions of daily active sessions, proxying to downstream analytics targets.

---

4. The GitOps Deployment Pipeline

Dukaan uses a strict GitOps model that decouples Continuous Integration (CI) from Continuous Delivery (CD).

sequenceDiagram
    autonumber
    actor Dev as Developer
    participant GH as GitHub Repository (App Code)
    participant CI as GitHub Actions (CI)
    participant Reg as Docker Container Registry
    participant InfraRepo as GitHub (team-dukaan-infra)
    participant Argo as ArgoCD (Bare Metal)
    participant K8s as Edge Kubernetes Clusters

    Dev->>GH: Push / Merge code to production branch
    GH->>CI: Trigger Build Pipeline
    CI->>CI: Extract Commit Hash (Last 5-6 chars as tag)
    CI->>Reg: Build & Push Docker Image
    CI->>InfraRepo: Update target service manifest with new tag
    InfraRepo-->>Argo: ArgoCD monitors infra repo (Polling/Webhook)
    Argo->>Reg: Pull new container image
    Argo->>K8s: Reconcile state & execute rolling deployment

How Deployments Work Without SRE Bottlenecks

1. Developer Commits Code: Developers merge changes into protected production branches.
2. CI Image Tagging: GitHub Actions builds the Docker image and tags it using a short commit hash extracted directly from git rev-parse.
3. Declarative Config Updates: The CI job commits an update directly to a centralized team-dukaan-infra Git repository, updating the image:tag field in the relevant Kubernetes manifest.
4. ArgoCD Reconciliation: ArgoCD constantly watches the infrastructure repository. When a diff is detected, it automatically synchronizes and updates the pods across edge clusters using rolling zero-downtime updates.
5. Developer Observability via Lens IDE: Instead of maintaining a large dedicated DevOps team, Dukaan grants service developers access to Lens (a desktop Kubernetes IDE). Developers inspect their own pod metrics, trace logs, and debug failures directly.

---

5. Hybrid Disaster Recovery (DR) and Data Safety

A common argument against bare-metal hosting is the fear of physical catastrophe: data center fires, hardware controller blowouts, or fiber cuts. Rather than building expensive physical multi-datacenter redundancies from scratch, Dukaan adopted a hybrid failover architecture.

Live Data Streaming to Cloud

• Primary Database: Hosted on bare metal with locally attached enterprise NVMe storage.
• Continuous Streaming Replication: The primary PostgreSQL instance continuously streams transaction changes to a standby PostgreSQL replica hosted in the cloud (GCP/AWS).
• Point-in-Time Recovery (PITR): Write-Ahead Logs (WAL) and compressed database snapshots are backed up continuously to cloud object storage (Google Cloud Storage / Amazon S3).

The Recovery Plan

If an entire bare-metal facility goes offline, recovery requires executing an automated recovery runbook:

1. Promote the Cloud Replica: Run a promotion command on the cloud PostgreSQL standby replica, converting it into the new primary read/write instance.
2. Spin Up Kubernetes Worker Nodes: Spin up or scale an active cloud Kubernetes cluster.
3. Apply Declarative Manifests: Apply the existing infrastructure manifests via ArgoCD or kubectl apply -f.
4. Update Edge DNS/Routing: Point external CDN/DNS records to the cloud ingress endpoint.

• Recovery Time Objective (RTO): Approximately 7 to 10 minutes (worst-case ~30 minutes).
• Recovery Point Objective (RPO): Near-zero data loss (limited strictly to un-flushed replication packets).

Accepting a rare ~15-minute downtime window in an extreme disaster scenario enables the team to maintain a 90% lower baseline infrastructure cost without sacrificing permanent data durability.

---

6. Solving Sudden Traffic Surges: The Global Follow-the-Sun Strategy

One major architectural challenge of running on bare metal is handling unpredictable, extreme traffic spikes.

The “Shark Tank” Problem

When a merchant featured on national television (e.g., Shark Tank) airs, platform traffic can jump from 50 concurrent users to 80,000+ active users in under 30 seconds.

• Why Cloud Autoscaling Fails Here: Cloud-native Horizontal Pod Autoscalers (HPA) and cloud VM autoscalers take several minutes to detect metrics, request new compute instances, boot OS images, join the Kubernetes cluster, pull multi-gigabyte container images, pass health checks, and register behind load balancers. By the time the instances are ready, the burst traffic has already overwhelmed the application or subsided.
• The Bare-Metal Provisioning Dilemma: Keeping peak capacity provisioned 24/7 on a single server rack is cost-prohibitive.

Global Follow-the-Sun Load Shifting

Dukaan solved this through distributed edge routing across ~22 geographic server locations:

graph LR
    Spike([Flash Traffic Spike in India]) --> EdgeLB[Regional Edge Ingress - Mumbai]
    
    EdgeLB -->|Local Capacity Normal| LocalCompute[Local Bare-Metal Cluster]
    EdgeLB -->|Capacity Exceeded > 85%| ProxyRouter{Global Edge Proxy Engine}
    
    ProxyRouter -->|Off-Peak Night Hours| EUCluster[Europe Cluster - Amsterdam]
    ProxyRouter -->|Off-Peak Night Hours| USCluster[US Cluster - N. Virginia]

1. Geographic Load Offsetting: Because of differing global time zones, when traffic peaks during evening prime time in India, server clusters in Europe and the Americas sit virtually idle.
2. Threshold-Based Proxying: Every regional ingress node monitors its local compute utilization. When a local cluster hits its safe operating ceiling, excess connections are dynamically reverse-proxied over low-latency backbones to clusters in off-peak time zones.
3. The Trade-Off: Requests redirected to another continent incur an extra 150–200ms network round-trip delay. For an e-commerce storefront, an extra 200ms latency during an extreme flash sale is imperceptible to users and preserves full platform availability without dropping requests or paying for idle peak infrastructure.

---

7. Architectural Trade-offs: Cloud vs. Bare Metal

Architectural Vector	Standard Hyperscale Cloud	Dukaan’s Bare-Metal Approach
Cost Structure	Variable, metered by usage; high network egress & IOPS fees.	Fixed, predictable hardware leases; negligible egress costs.
Storage Performance	Network-attached virtual block storage (throttled IOPS, higher latency).	Locally attached enterprise NVMe (PCIe direct, massive IOPS, ultra-low latency).
Disaster Recovery	Built-in multi-AZ primitives managed by provider.	Hybrid: Local primary with live streaming to cloud standby replica and S3/GCS.
Autoscaling Mechanics	Reactive spinning up of virtual machines (takes 3–10 minutes).	Follow-the-sun global edge routing to divert spikes to off-peak regions.
Operational Overhead	Low hardware management; higher infrastructure configuration complexity.	Requires systems knowledge (RAID, disk failure recovery, Linux internals), but simplified operations via GitOps.
Vendor Lock-in	High if using proprietary managed services (DynamoDB, Bigtable, SQS).	Zero; relies exclusively on open-source software (PostgreSQL, RabbitMQ, K8s).

---

Key Takeaways

1. Cloud is Not an Architectural Requirement: While cloud platforms provide velocity for early prototypes, mature companies with predictable base traffic patterns and strong in-house systems expertise can achieve orders-of-magnitude cost savings and superior raw performance on bare metal.
2. I/O Latency Dictates Database Scale: Eliminating distributed virtual block layers in favor of direct-attached NVMe drives drastically reduces transactional write latency and unlocks maximum database throughput.
3. Pragmatic Disaster Recovery Over Idealized Perfection: A hybrid DR strategy—streaming real-time database logs to cloud object storage and standby replicas—provides rock-solid data safety without the massive cost of continuously running redundant multi-region cloud clusters.
4. Design for Portability: Sticking to standard open-source primitives (PostgreSQL, Docker, Kubernetes, Celery, RabbitMQ) ensures that workloads can transition between cloud providers and physical data centers without rewriting application code.