Supercharge Your Applications with Dragonfly Cloud on GCP

Dragonfly Cloud Available on Google Cloud Marketplace

Dragonfly is a multi-threaded, high-performance, Redis-compatible in-memory data store, and Dragonfly Cloud delivers it as a fully managed service across major cloud platforms. For teams running latency-sensitive applications—from session stores to real-time analytics and caching layers—Dragonfly Cloud offers a compelling alternative to traditional Redis deployments, providing higher throughput, lower latency, seamless scalability, simplified operations, and reduced costs.

After previously being available on AWS, Azure, and GCP, we’re excited to announce that GCP customers can now deploy Dragonfly Cloud resources directly via Google Cloud Marketplace. This integration simplifies procurement, billing, and deployment, letting you focus on building fast applications rather than managing infrastructure.

In this post, we’ll explore how Dragonfly Cloud supercharges your workloads along with other GCP infrastructure services—whether you’re scaling microservices or accelerating AI-related capabilities. Let’s dive in!

Use Case | Session Storage for Serverless Web Apps

Serverless computing has revolutionized how we deploy applications by abstracting away infrastructure management. Services on GCP like Cloud Run (for containers) and Cloud Run Functions (for event-driven function-centric code) automatically scale to zero when idle and instantly scale up during traffic spikes—all while you only pay for actual usage. This model offers a few key advantages:

• Zero Server Management: No provisioning, patching, or capacity planning required.
• Cost-Efficient Scaling: Pay-per-execution pricing eliminates idle resource costs. However, I’d argue that for steady or steadily growing workloads, the serverless pricing model would have a negative impact. When an application has such workloads, careful capacity planning using dedicated resources can save big bucks.
• Automatic Scalability: Handles traffic bursts and scales down to zero seamlessly without manual intervention.

However, being serverless comes with a critical tradeoff: it’s stateless by design. This is generally true for many backend applications despite their deployment environments, but serverless pushes the pattern to the extreme. While serverless simplifies scaling, it creates challenges for web applications that need to maintain user sessions—whether for authentication tokens, shopping carts, or temporary preferences. Traditional on-disk databases like Cloud SQL introduce latency bottlenecks, while file-based solutions become unwieldy at scale. This is where Dragonfly Cloud shines. As a Redis-compatible, hosted in-memory data store with microsecond-scale reads/writes, it can be utilized as a perfect state layer for serverless applications:

• Sub-Millisecond Latency: Performs like local memory while being shareable across container instances and serverless function executions.
• Fully Managed: No operational overhead vs. self-hosted solutions, and now part of Google Cloud Marketplace.
• Multi-Threaded Architecture: Handles massive traffic spikes without throttling and with steady latency expectations.

Implementation: Cloud Run + Dragonfly Cloud

While Cloud Run follows the container model—where instances are ephemeral and workloads should be stateless—certain stateful dependencies are unavoidable. A prime example is maintaining persistent connections to external services like Dragonfly Cloud. Here are some considerations:

• Stateless ≠ No Connections: Cloud Run allows (and encourages) establishing connection pools to databases or data stores during container initialization. These connections persist across requests until the instance is terminated.
• Performance Gains: Reusing connections avoids the overhead of re-authenticating/re-handshaking for every request, which is critical for low-latency workloads.

// https://github.com/redis/ioredis
import { Redis as Dragonfly } from 'ioredis';
import express from 'express';

// Express application.
const app = express()
app.use(express.json())

// Initialize Dragonfly connection pool when container boots.
// Note that we can use existing Redis client libraries in the ecosystem for Dragonfly.
const dragonfly = new Dragonfly({
  host: 'YOUR_DRAGONFLY_CLOUD_ENDPOINT',
  port: 6379,
  password: 'YOUR_PASSWORD',
  maxRetriesPerRequest: 1,
  enableReadyCheck: true,
});

// The connection pool can be resued across requests.
app.post('/login', async (req, res) => {
  // Verify user credentials.
  // ...

  const sessionId = generateId();
  await dragonfly.set(`session:${sessionId}`, JSON.stringify(req.user), 'EX', 86400);
  res.cookie('sessionId', sessionId);
});

// Graceful shutdown, which is optional but recommended.
process.on('SIGTERM', () => {
  dragonfly.quit();
});

Cloud Run’s instance lifecycle enables important performance optimizations. Since idle instances remain active for approximately 15 minutes, maintaining persistent Dragonfly connections across requests eliminates repeated handshake overhead. This is where connection pooling provides its greatest value. For production reliability, we can configure client options such as enableReadyCheck, ensuring connections are healthy before use, and maxRetriesPerRequest for retrying commands that don’t get a reply due to the connection to the server being lost. These are just two examples of how you can customize your client behavior and make it more robust.

Also, it is recommended to implement a SIGTERM handler. Cloud Run uses this signal to notify instances of shutdown, allowing your application to gracefully close connections and complete pending operations. This prevents resource leaks and ensures clean instance termination.

Implementation: Cloud Run Functions + Dragonfly

For serverless functions where maintaining TCP connections would negate the benefits of stateless execution, Dragonfly provides an experimental HTTP API (enabled via the --expose_http_api server flag). This approach eliminates connection management overhead. When enabled, you can interact with Dragonfly by sending complete commands as JSON arrays, for example ["SET", "session:123", "user_data", "NX"], which includes the command, arguments, and any options as sequential array elements. Each HTTP request contains everything needed for execution, making it perfectly self-contained.

While this method has slightly higher per-command overhead (due to repeated authentication for instance), it’s often more efficient for Cloud Run Functions since it eliminates connection pool management complexity and avoids wasted resources when connections would only be used once. Here’s how to implement it in practice:

// A generic helper for the Dragonfly HTTP API.
async function callDragonfly(command: string[]) {
  const response = await fetch('http://DRAGONFLY_CLOUD_ENDPOINT:6379', {
    method: 'POST', 
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(command),
  });

  if (!response.ok) {
    const errorText = await response.text();
    throw new Error(`Dragonfly error: ${errorText}`);
  }

  return await response.json();
}

This HTTP API remains an experimental feature in Dragonfly, making it particularly well-suited for prototyping and low-to-moderate traffic workloads. For production environments that demand high throughput, we continue to recommend traditional TCP connections—which explains why this capability isn’t yet included in Dragonfly Cloud. That said, our team has consistently demonstrated our commitment to evolving Dragonfly based on community needs. If this HTTP API would be valuable for your production use cases, we’d love to hear from you. Your feedback (share with us in Discord!) could directly influence our development priorities and help accelerate this feature’s path to becoming fully production-ready.

Use Case | Caching Layer for Your GCP Databases

While user sessions are essential, every application needs fast access to its core business data—typically stored in persistent GCP database services like Cloud SQL, AlloyDB, BigTable, or Spanner. These solutions deliver exceptional durability and scale, but even optimized disk-based systems operate in the millisecond latency range. This is where Dragonfly shines as a caching layer, delivering microsecond-scale reads that are 10-100x faster than direct database access.

The transition from other caching solutions to Dragonfly is remarkably smooth. Thanks to its Redis compatibility, most applications can switch with just a connection URI change—no client library replacements or code refactoring needed. Under the hood, Dragonfly’s multi-threaded architecture handles heavy loads without the bottlenecks of traditional Redis or Valkey-based solutions.

From a cost perspective, Dragonfly Cloud’s ”size of provisioned memory” pricing model creates compelling economics: by caching frequently accessed data, you reduce expensive database queries that would otherwise require scaling up your primary database compute resources. This is particularly valuable for read-heavy workloads (e.g., product catalogs), computationally expensive queries, and other frequently accessed data. Here’s an example cache-aside strategy:

// https://github.com/redis/ioredis
// https://github.com/brianc/node-postgres
import { Redis as Dragonfly } from 'ioredis';
import pg from 'pg';

const { Pool } = pg;
const db = new Pool({ /* Cloud SQL Connection Credentials */ });
await db.connect();

const cache = new Dragonfly({
  host: 'YOUR_DRAGONFLY_CLOUD_ENDPOINT',
  port: 6379,
  password: 'YOUR_PASSWORD',
});

async function getProduct(productId: string) {
  // Check cache first.
  const cached = await cache.get(`product:${productId}`);
  
  // Cache hit, respond directly!
  if (cached) return JSON.parse(cached);

  // Cache miss, fall back to database.
  const { rows } = await db.query('SELECT * FROM products WHERE id = $1', [productId]);

  // Before returning, cache the data in Dragonfly for future access with auto-expiration.
  if (rows[0]) {
    await cache.set(
      `product:${productId}`, 
      JSON.stringify(rows[0]),
      'EX', 3600 // TTL in seconds
    );
  }

  return rows[0] || null;
}

While this covers the fundamentals, caching strategies become increasingly nuanced at scale. For developers looking to master advanced patterns:

• Our guide, Developing with Dragonfly: Cache-Aside, dives into implementation details, including cache population strategies and middleware usage.
• The follow-up Developing with Dragonfly: Solving Caching Problems tackles real-world challenges like cache penetration (preventing database floods from cache misses), cache breakdown (hot key expiration storms), and cache avalanches (mass expirations).

These resources will help you transform basic caching into a robust performance layer with best practices.

Your GCP Stack, Supercharged with In-Memory Data

In this post, we’ve explored two fundamental patterns for supercharging GCP applications with Dragonfly Cloud: session storage for serverless workloads and high-speed caching for database performance. But these are just the beginning. Dragonfly’s rich data structures are versatile and can handle other use cases like real-time statistics, streaming pipelines, AI/ML feature stores, and many more. We can’t wait to see what you build next!