Plan data access with Valkey.

Valkey-Bloom is loaded separately; it is built for Valkey 8.1 and later, with a specific build option for 8.0. Verify module availability in the service. Check possible matches against the source of truth and fall back when the filter is incomplete or stale.

• Transaction locations. Previously used locations can be pre-checked; a new location alone is not proof of fraud.
• Device, IP and email history. Check whether a device or address associated with a user has been seen; authentication remains separate.
• Merchant, category and amount bands. User, merchant, category and application-defined amount bands can provide signals for risk assessment.
• Known risk records. Pre-check lost or stolen cards and risk identifiers; verify possible matches against the authoritative list.
• Missing records. A complete, current filter can screen out absent product, account or document IDs before a database lookup.
• Usernames, email addresses and content URLs. Pre-check names that may already be used; the database enforces uniqueness.
• Repeated ads. Ads that may have been shown can be screened out; impression limits need separate counters.
• Content, product and friend recommendations. Screen out candidates that may have been seen; false positives can also hide new candidates.
• Visited URLs. Identify addresses that may have been visited; the application manages recrawl schedules.
• Repeated events and webhooks. Verify possible duplicates against authoritative records; the filter alone does not guarantee exactly-once processing.
• Files and data blocks. Verify possible duplicates in the disk index; never discard new data on the filter result alone.
• Malicious addresses. Verify possible URL, domain or IP matches; absence from the list does not guarantee safety.
• Dictionary pre-check. Verify possible word matches in the dictionary; the filter does not suggest corrections.
• Disk-file reads. File or block summaries can screen out irrelevant reads; storage-layer integration is required.
• Parquet segments. Pre-screen column segments with custom integration; Parquet’s own filter is a separate implementation.
• Log and trace blocks. Screen out blocks without an identifier; custom indexing and query integration are required.
• Pre-join screening. Screen out keys that cannot match; the query engine still performs the actual join.
• Distributed cache directory. Use summaries to select candidate nodes, verify contents at the node and keep summaries current.

Valkey-Bloom does not provide Cuckoo filters. Some needs can use exact membership in Valkey sets; memory use, expiry and concurrency have different trade-offs.

• Campaign audience. Remove confirmed participants from the candidate set; keep participation records separately.
• Coupons. Pre-check valid codes; the primary system enforces single-use rules under concurrent requests.
• Changing risk and trusted lists. Add or remove devices and accounts as reviews change their status.
• Revoked tokens and API keys. Pre-check revocation records; signature, expiry and authorization checks remain separate.
• Sessions and online devices. Update membership on session or WebSocket opening and confirmed closure; retain the actual state separately.
• Active catalogue and stock. Pre-check active products; stock quantities and reservations remain in the source of truth.
• Cache nodes. Track candidate nodes for objects; coordinate removal with cache invalidation.
• Time-limited event and URL tracking. Track IDs seen during a period; the application manages expiry and removal.
• Reversible content preferences. Use reversible preferences to filter candidates while retaining the authoritative preference record.
• Jobs and subscriptions. Pre-check pending jobs or active subscriptions; locking and authorization are handled separately.

Valkey-Bloom does not provide Count-Min Sketch. Some frequency needs can use Valkey counters; approximate sketches need an appropriate additional component. Time windows and aggregation require separate design.

• Product demand. Track sales or views per product; financial records remain separate.
• Sign-in attempts. Rising attempts per user or IP can signal a review; verify before enforcing a hard block.
• Card–merchant repeats. Transaction-pair frequency can inform risk assessment; it is not proof of fraud on its own.
• API usage and quotas. Inspect busy customers and endpoints; billing and hard quotas rely on separate records.
• Ad impression frequency. Track impression volume by user and campaign; contractual counts are kept separately.
• Logs, errors and device events. Track frequency of known error codes or device events while retaining raw records.
• Words, n-grams and search terms. Compare frequencies of known terms; the application handles text parsing.
• Cache admission. Access frequency can help compare candidates; admission and aging policies require separate design.
• High-traffic candidates. Compare known candidates against total traffic; candidate IDs come from a separate stream.
• Regional counts. Combine compatible regional or period summaries; duplicate events need separate handling.

Valkey-Bloom does not provide Top-K. Counters and sorted sets can rank frequencies; this differs from an approximate Top-K sketch and requires data and time-window management.

• Trending tags and content. List frequently seen tags or content for a selected period.
• Popular searches. Find frequent search terms; frequency does not imply personal interest or semantic importance.
• Popular products. Rank product candidates from sales or views; retain exact sales reports separately.
• Busy network flows. Inspect busy flows by packet frequency, IP, port and protocol; measure the cost of transferring the data.
• Bot and attack investigation. Select busy sources for investigation; high traffic alone is not proof of an attack.
• Hot keys and content. Frequently accessed keys or CDN content can inform cache or capacity work; the follow-up action is separate.
• Endpoint and customer traffic. Identify busy endpoints or customer groups; request counts are not processing costs.
• Common error signatures. Review frequent errors; rare critical errors still need separate alerts.
• Activity and game lists. Build activity-based lists; exact rewards and scores need separate records.
• Actions when a list changes. The application can update a display or review queue when its candidate list changes.

Valkey-Bloom does not provide t-digest. These distribution calculations require a suitable application library or separate analytics component; support and version requirements must be assessed.

• API and database latency. Use p50, p95 and p99 to inspect response-time distributions; interpret extreme percentiles cautiously with few observations.
• SLO thresholds. Estimate where a duration falls in the distribution; account for ties in the CDF and keep a separate counter for exact violations.
• Trimmed mean. Estimate the mean within a chosen percentile range; excluded extremes still need monitoring.
• Game score percentiles. Compare a score with a historical distribution; exact player rankings are maintained separately.
• Unusual network traffic. Compare measurements with historical percentiles; crossing a threshold alone does not prove an attack.
• IoT and maintenance. Compare temperature or current measurements with typical ranges to select equipment for review.
• Combining distributed measurements. Combine compatible distribution summaries; do not directly average separate p99 values.
• Transaction amounts. Compare amount distributions within similar transaction groups; a high amount alone does not prove risk.
• Queue and delivery times. Summarize waiting and completion times; keep job IDs and event order separately.
• A/B and version comparisons. Compare latency distributions across groups; assess statistical significance separately.

Valkey’s built-in HyperLogLog estimates distinct counts; it cannot list people or check individual membership. Period summaries are merged rather than added.

• Distinct visitors. Estimate distinct visitor IDs in a period; an IP address does not always represent one person.
• Video and music reach. Estimate distinct viewers or listeners per item; measure playback duration separately.
• Distinct search queries. Track diversity of normalized queries; lists and frequencies are kept separately.
• Crawl coverage. Estimate how many distinct URLs were reached; individual URL membership cannot be queried.
• Daily, weekly and monthly users. Merge daily summaries for a period estimate; do not add daily counts.
• Campaign reach. Merge user summaries across channels; matching identities across channels is the application’s responsibility.
• Counts across regions and services. Estimate the union of identifiers from summaries of different sources.
• IP, account and device diversity. Distinct accounts per IP or devices per account can provide a risk signal.
• Active IoT devices. Estimate devices reporting in a period; use separate records to identify offline devices.
• Customer and product diversity. Estimate distinct customers or products sold; orders and revenue are measured separately.
• Data profiling. Track changes in distinct field values; this does not replace exact uniqueness checks.
• Log and metric diversity. Track diversity of errors or labels; separate records identify the values behind an increase.

Valkey-Bloom can provide pre-screening; these patterns still require separate routing, error-correction, graph-processing or reconciliation algorithms.

• IP prefix routing. Pre-check prefix lengths in separate filters; longest-match and routing logic must be built separately.
• Layered blocklists. Design layered filters for certificate or extension lists; scope and false-positive correction need separate handling.
• Bioinformatics graphs. Summarize sequence fragments with filters; graph construction and false-branch correction require separate algorithms.
• Distributed set reconciliation. Combine Bloom pre-screening with a reconciliation protocol; the filter alone cannot list missing items.