Topic

Scylla

2 posts about Scylla. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Posts

Grab
Counter Service: How we rewrote it in Rust
The Integrity Data Platform team rewrote Counter Service, a high-QPS Golang microservice that consumes streams, writes counts to Scylla, and exposes gRPC queries backed by Scylla and Redis. They selected it because BatchRead reached tens of thousands of QPS while remaining constrained in functionality, making infrastructure savings potentially worth the rewrite effort and Rust learning curve. Rather than translating code line by line, the team treated the existing service as a black box, preserved its interfaces and contracts, and rebuilt the application logic from scratch; it also assessed Rust ecosystem support for dependencies including tonic, Actix Web, Fred, and the Scylla driver. The rewrite delivered similar performance with 70% infrastructure savings, according to the abstract. The conclusion reports the service as 80% cheaper, endorses Rust for new services, and cautions that async Rust is challenging.

Grab
Evaluating performance impact of removing Redis-cache from a Scylla-backed service
A Rust service at Grab serves tens of thousands of peak QPS for batched count requests, using Scylla, Redis, and MySQL counter configurations. Its 15-minute cache-key truncation and five-minute TTL caused cache-hit declines and recurring Scylla QPS spikes at the end of each quarter-hour, when recent-data requests generated new keys. The experiment progressively disabled Redis, while a daily major compaction job was added to Scylla nodes; the service continued combining minutely, hourly, and daily tables for range calculations. With Redis fully decommissioned, Scylla cache hits rose from about 30% to 70% of reads, cache misses stayed about the same despite doubled traffic, peak CPU moved from roughly 50% to 52%, and overall service performance was maintained while eliminating a component responsible for about 25% of service cost.

The best engineering reads, once a week.

Topic

2 posts about Scylla. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Grab
Counter Service: How we rewrote it in Rust
The Integrity Data Platform team rewrote Counter Service, a high-QPS Golang microservice that consumes streams, writes counts to Scylla, and exposes gRPC queries backed by Scylla and Redis. They selected it because BatchRead reached tens of thousands of QPS while remaining constrained in functionality, making infrastructure savings potentially worth the rewrite effort and Rust learning curve. Rather than translating code line by line, the team treated the existing service as a black box, preserved its interfaces and contracts, and rebuilt the application logic from scratch; it also assessed Rust ecosystem support for dependencies including tonic, Actix Web, Fred, and the Scylla driver. The rewrite delivered similar performance with 70% infrastructure savings, according to the abstract. The conclusion reports the service as 80% cheaper, endorses Rust for new services, and cautions that async Rust is challenging.

Grab
Evaluating performance impact of removing Redis-cache from a Scylla-backed service
A Rust service at Grab serves tens of thousands of peak QPS for batched count requests, using Scylla, Redis, and MySQL counter configurations. Its 15-minute cache-key truncation and five-minute TTL caused cache-hit declines and recurring Scylla QPS spikes at the end of each quarter-hour, when recent-data requests generated new keys. The experiment progressively disabled Redis, while a daily major compaction job was added to Scylla nodes; the service continued combining minutely, hourly, and daily tables for range calculations. With Redis fully decommissioned, Scylla cache hits rose from about 30% to 70% of reads, cache misses stayed about the same despite doubled traffic, peak CPU moved from roughly 50% to 52%, and overall service performance was maintained while eliminating a component responsible for about 25% of service cost.

The best engineering reads, once a week.