Overview
TopK provides two consistency levels that let you balance between query performance and data freshness. Understanding these consistency models helps you optimize your application for specific use cases.Consistency Levels
TopK supports two consistency levels for read operations:- Indexed (Default)
- Strong
Indexed consistency returns results as soon as they are indexed, providing:
- Faster query performance
- Eventual consistency guarantees
- Ideal for read-heavy workloads where absolute freshness isn’t critical
Using LSN for Consistency
TopK uses Log Sequence Numbers (LSN) to track the order of operations. Every write operation returns an LSN that you can use to ensure read-your-own-writes consistency.How LSN Works
When you perform a write operation (upsert, update, or delete), TopK returns an LSN representing that operation’s position in the log:- JavaScript
- Python
Read-Your-Own-Writes Pattern
The most common use case for LSN is ensuring that queries immediately see data you just wrote:Get Operations with LSN
You can also use LSN withget() operations to ensure you’re retrieving the latest version:
When to Use Each Consistency Level
Use Indexed Consistency
Use Indexed Consistency
Choose indexed consistency when:
- You’re running read-heavy analytics or search queries
- Slight data staleness (milliseconds) is acceptable
- You want to maximize query throughput
- You’re not immediately querying data you just wrote
Indexed consistency typically provides sub-10ms latency for most queries.
Use Strong Consistency
Use Strong Consistency
Choose strong consistency when:
- You need guaranteed fresh data for every query
- You’re implementing critical business logic
- You’re running queries after user-initiated writes
- Data accuracy is more important than latency
Use LSN-Based Consistency
Use LSN-Based Consistency
Choose LSN-based consistency when:
- You need to query data immediately after writing it
- You want read-your-own-writes guarantees
- You’re implementing optimistic UI updates
- You need point-in-time consistency without full strong consistency overhead
Performance Implications
Latency Comparison
| Consistency Level | Typical Latency | Use Case |
|---|---|---|
| Indexed (default) | 5-15ms | General queries, analytics |
| LSN-based | 10-20ms | Write-then-read patterns |
| Strong | 20-50ms | Critical data requirements |
Latency varies based on data size, query complexity, and geographic distribution.
Throughput Considerations
- Indexed consistency: Highest throughput, queries can be served from any replica
- LSN-based consistency: High throughput, waits only for specific LSN to be replicated
- Strong consistency: Lower throughput, requires coordination across all replicas
Best Practices
- Default to indexed consistency for most queries unless you have specific freshness requirements.
-
Use LSN for write-then-read patterns instead of strong consistency:
- Batch writes when possible to minimize the number of LSN checks needed.
- Monitor query performance and adjust consistency levels based on your application’s requirements.
QueryOptions Interface
All read operations in TopK accept an optionalQueryOptions parameter:
QueryOptions:
query()- Execute queries with consistency controlcount()- Count documents with consistency guaranteesget()- Retrieve documents with specific consistency requirements