Tips on Schema, Queries, Parallel Access, and Reactive Programming
summary
Designs a backend for an authenticated social feed with concrete CQL schemas and query patterns, chooses ULID / UUIDv7 for time-sortable IDs, keeps counters in a separate post_stats table, and pins pagination to a start timestamp using a capped count (limit 1,000) to avoid full scans. Converts 81 sequential queries into bulk and parallel lookups, collapsing to ~two IO steps and ~23 queries by batching stats and relationships, implements a POC with Kotlin Quarkus Mutiny and reports 3.72 ms median response.
AI-written summary · about
chapters (20)
- 0:00Cassandra intro and overview
- 2:12Cassandra challenges and trade-offs
- 3:19Social feed API use case
- 7:17Data entities and relationships
- 8:23Access patterns and query design
- 11:56Primary keys and schema design
- 14:23Handling counters and tables
- 16:10Pagination and counting posts
- 18:41Query optimization process
- 20:25Schema and query refinement
- 23:17Bulk queries and parallel access
- 25:49Query count and response time
- 26:54Caching user data
- 27:16Non-blocking I/O and reactive benefits
- 30:10Reactive with Quarkus and Mutiny
- 33:24Performance results and traces
- 34:06Conclusion and when to use
- 37:16Reactive learning curve
- 38:42Blue Sky’s Cassandra migration
- 39:25Q&A
related talks
47mFrom Imperative to Reactive Programming
38mAccelerating Query Performance in CrateDB
28mModernizing App Development: Planet-scale GraphQL & Distributed SQL
26mLess Code, Faster Apps- Rediscovering SQL for Modern ORM Developers
48mCompositional, Expressive, Performant Database Queries: Choose 3
31mUsing Databases to pull your applications weight
28mMoving Towards Real-Time OLAP - With First Principle Thinking and Guided by Access Patterns
25mOptimizing GraphQL Applications