Request for Guidance: Using ScyllaDB for API Response Caching (POC in Progress)

ScyllaDB
, , ,
1

Dear ScyllaDB Team,

I am currently working on a POC (Proof of Concept) using ScyllaDB on-prem trial version as a caching layer for some of our APIs, such as transaction history , account summary etc. The goal is to reduce load on our primary database and serve frequently accessed responses with low latency.

As part of this POC, I want to validate the best approach and architecture to utilize ScyllaDB effectively for this scenario. Below are some design options I am considering, and I would appreciate your input or alternative recommendations. Please feel free to suggest best alternatives, your guidance would be very valuable:

Request Hash–based Caching

  1. Request Hash-based Caching

    1. Store API responses against a unique request hash.

    2. Example:

      CREATE TABLE api_cache.responses (
  request_hash TEXT PRIMARY KEY,
  endpoint TEXT,
  response TEXT,
  created_at TIMESTAMP
);

    3. Concern: If requests grow into millions, ScyllaDB may accumulate old unused data.

    4. Question: Should we rely on TTL for automatic cleanup, or are there better strategies for eviction and cache invalidation?

  2. Parameter–based Caching (Storing input params as columns)

    1. Save request parameters directly as columns with the API response.

    2. Example:

      CREATE TABLE api_cache.transaction_history (
  account_id TEXT,
  from_date DATE,
  to_date DATE,
  response TEXT,
  PRIMARY KEY ((account_id), from_date, to_date)
);

    3. Concern: If new request parameters are introduced later, schema evolution may be required.

    4. Question: Is this a recommended approach for caching APIs where input parameters may evolve over time?

  3. Cluster Sizing & Replication Factor
    1. For a read-heavy caching workload with medium writes, how many nodes would you recommend starting with?
    2. What replication factor is best suited for caching scenarios where fast retrieval is critical but cost efficiency also matters?
  4. Integration with .NET Core Middleware
      1. Our APIs are developed in .NET, and we are planning a middleware that decides whether to fetch data from ScyllaDB or the primary DB.
      2. Question: Are there recommended .NET client libraries or best practices for this integration pattern?

We would highly value your guidance on:

  1. The most suitable caching strategy (hash-based vs. param-based or hybrid).
  2. Best practices for TTL, cache invalidation, and handling schema evolution.
  3. Recommended cluster sizing for POC vs. production workloads.

As this is part of our ongoing POC, your suggestions will be critical in shaping our final architecture and ensuring that we leverage ScyllaDB’s strengths effectively.

Looking forward to your recommendations.

Best regards,
Dadasaheb

2

What is the primary database you’re using?
Some users started out using ScyllaDB as a caching layer, but later switched the entire database to ScyllaDB to get better results. This webinar is a useful resource.

A replication factor of three works for many use cases.

Regarding sizing, it really depends, what is your payload size?

This database and cache internals blog post might also be relevant, and maybe can add more info.