Dripshop.live

Dripshop Infrastructure Case Study

90% Cost Reduction

How Dripshop Migrated from GCP Kubernetes to Dedicated Servers

$20K Before (GKE) → $2K After (Dedicated)

🎯 The Result

52,000 TPS at the database layer. 10,000+ concurrent users. 90% cost reduction.

This is the story of how we did it—and why managed infrastructure isn't always the answer.

❌ The Problem: GKE at Scale Gets Expensive

Dripshop started on Google Kubernetes Engine—the standard choice for modern containerized applications. But as traffic grew, so did the bill.

💸 $20,000/month

Monthly GKE infrastructure spend including compute, managed databases, and egress costs for global users.

📦 20 Instances at Peak

During NFT drops, we scaled to 20 instances (16 vCPU, 32GB RAM each). Total: 320 vCPUs, 640GB RAM.

⏱️ 75ms Latency

PgBouncer connection pooling became a bottleneck, adding significant latency to database operations.

📈 Overprovisioning

Node pools required overprovisioning to handle traffic spikes, meaning we paid for resources we rarely used.

🐘 AlloyDB: "Managed" But Not Really

GCP's AlloyDB promised a fully managed PostgreSQL experience, but reality was different. We still had to manually tune work_mem, shared_buffers, and other parameters. It only supported PgBouncer for connection pooling—no Odyssey option. Managed in name, DIY in practice.

The Real Problem: We were paying premium prices for "managed" services while still doing the optimization work ourselves—and hitting the limits of single-threaded tools.

🤔 The Decision: Going Against the Grain

The cloud-native playbook says use managed Kubernetes.

It's "easier to operate." It "scales automatically." It's "the modern way." But we asked ourselves: what are we actually paying for?

Auto-scaling → We could handle this ourselves with PM2 cluster mode

Managed control planes → We didn't need them for a stable workload

Premium pricing → We were paying cloud tax on commodity compute

The New Infrastructure

Three dedicated servers from ServerBasket—bare metal machines with serious specifications:

GCP Kubernetes $20K → Dedicated Servers $2K

🏗️ The Architecture: Three Servers, Zero Compromise

We split responsibilities cleanly across three dedicated servers, each with 256 cores and 768GB RAM.

1

Server 1: Backend

256 cores • 768GB RAM

  • 🔄 PM2 Cluster Mode
  • ⚡ 200 Node.js Workers
  • 🌐 API + Business Logic
  • 📊 Load Balancing
2

Server 2: Cache + Search

256 cores • 768GB RAM

  • 🐉 DragonflyDB (Redis)
  • 🔍 OpenSearch
  • 🔐 Session Store
  • 📦 Queue Management
3

Server 3: Database

256 cores • 768GB RAM

  • 🐘 PostgreSQL 18
  • 🌊 Odyssey Pooler
  • 📍 PostGIS Extension
  • 🧩 19 Extensions

🔗 Why This Separation Works

Backend: Pure compute—no contention with I/O services. Cache: Memory-bound DragonflyDB + heavier OpenSearch queries isolated. Database: Full resources for PostgreSQL with massive shared_buffers allocation.

🧩 PostgreSQL Extensions: Supercharging the Database

We leverage 19 PostgreSQL extensions to optimize performance, enable advanced queries, and add specialized functionality.

🚀 Performance Extensions

  • pg_stat_statements for query analysis
  • pg_buffercache for buffer inspection
  • pg_prewarm for cache warming
  • pg_visibility for visibility maps

🔍 Search & Indexing

  • pg_trgm for fuzzy text search
  • fuzzystrmatch for string matching
  • bloom for bloom filter indexes
  • btree_gin / btree_gist for composite indexes

🌍 Geospatial (PostGIS)

  • postgis for spatial data
  • postgis_raster for raster data
  • postgis_topology for topological models
  • postgis_tiger_geocoder for US geocoding

🛠️ Data Types & Utilities

  • uuid-ossp for UUID generation
  • pgcrypto for encryption
  • hstore for key-value storage
  • citext / intarray / tablefunc

💡 Why Extensions Matter

These extensions let us handle fuzzy search, geospatial queries, advanced indexing, and performance monitoring inside PostgreSQL—eliminating the need for external services and reducing network round-trips.

🧪 The Experimental Stack

Instead of just migrating our existing stack, we re-evaluated every component with modern multi-core hardware in mind.

Connection Pooling: Odyssey

PgBouncer is single-threaded—on a 256-core machine, that's a bottleneck. Odyssey from Yandex is multi-threaded, using 64 worker threads to handle connections.

20x Faster

vs PgBouncer (2,650 → 51,807 TPS)

In-Memory Cache: DragonflyDB

Redis is single-threaded by design. DragonflyDB is a drop-in replacement that's multi-threaded from the ground up. Same API, dramatically better throughput on multi-core machines.

25x Faster

vs Redis on 256-core machine

Zero Code Changes Required: We exported Redis data as an RDB file and imported it directly into DragonflyDB. All existing Redis clients work without any modification—true drop-in replacement.

📊 Benchmark Results: Odyssey vs PgBouncer

We ran comprehensive benchmarks with 200 clients and 100 threads over 60 seconds. The results speak for themselves.

💡 Key Insight

Odyssey with 64 worker threads nearly matches direct PostgreSQL performance while still providing connection pooling, transaction management, and 10,000+ client connection support.

🐉 DragonflyDB vs Redis

🏆 The Results: Numbers Don't Lie

After completing the migration from GKE + AlloyDB to dedicated servers, here's where we landed:

52K

TPS

Database transactions per second—impossible to achieve with AlloyDB + PgBouncer limitations.

10K+

Users/sec

Concurrent users handled comfortably with room to spare.

45ms

P95

API response time at the 95th percentile—down from 150ms.

90%

Savings

Monthly infrastructure cost reduced from $20,000 to $2,000.

Resource Utilization

15-25%

CPU Average

30-35%

Memory Usage

3-4x

Growth Headroom

💡 The Irony

With dedicated servers, we have full control over PostgreSQL tuning—work_mem, shared_buffers, connection pooling—and achieved 52K TPS. The "managed" AlloyDB couldn't come close, yet cost 10x more.

Made with