Design data access with Redis.

Bloom filters can produce false positives and do not delete individual items. If the filter is incomplete or stale, use the source of truth; verify possible matches there.

• 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.

Cuckoo filters check possible membership and support removal. Remove only items known to have been inserted; the application manages concurrency, expiry and exact decisions.

• 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.

Count-Min Sketch estimates frequencies for known items. It does not discover candidates; time windows, hard quotas and financial records are managed separately.

• 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.

Top-K approximately tracks frequent candidates. The application manages time windows and follow-up actions; exact ranking is not guaranteed.

• 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.

t-digest produces approximate percentile and distribution results. Measurement windows, sample size and separate event records are part of the design.

• 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.

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.

Bloom is only one component in these patterns. Routing, error correction, graph processing or reconciliation require separate algorithms and custom integration.

• 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.