How to Detect a 30‑Day Continuous Sign‑In for 1 B Users with 1 GB Memory

A candidate was asked in a big‑company interview: with 1 billion users, 1 GB of memory, and a year of sign‑in data, how to tell whether a specific user has signed in for 30 consecutive days.

Storing each sign‑in as a MySQL row would require 10⁹ × 365 = 3.65 × 10¹² rows; at 20 bytes per row this is about 6.6 TB, far beyond the 1 GB limit. The sign‑in data only has two states (signed or not), so a single bit per day suffices: 365 bits ≈ 46 bytes per user, or 43 GB for all users—still large but now a tractable capacity problem.

The first pitfall is using BITCOUNT. It returns the total number of set bits but cannot distinguish whether those bits form a continuous block; e.g., 30 bits split into two 15‑day segments would still yield 30.

The core of the question is the key dimension. Two storage schemes are compared:

Store by day (key like sign:20260802): offset is uid, single key size ≈ 119 MB, good for queries such as “how many users signed today”, but poor for per‑user continuity checks (requires 30 network round‑trips).

Store by user (key like sign:u10086:2026): offset is day_of_year, single key size ≈ 46 bytes, ideal for “has user X signed 30 days straight?” and “which days did user X sign?”.

The recommended solution is to store the per‑user bitmap. A single GET retrieves the 46 bytes, and a local scan of 365 bits (nanosecond‑level) determines the longest consecutive streak. The article provides Java code for this scan and a five‑step bit‑wise trick:

x &= x >> 1;
x &= x >> 2;
x &= x >> 4;
x &= x >> 8;
x &= x >> 14; // non‑zero after these steps means a run ≥30

The trick works by repeatedly compressing adjacent 1‑bits; after the cumulative shifts, any remaining 1 indicates a continuous segment of at least 30 days.

In practice, large companies keep both representations: per‑user bitmaps in a cache layer for real‑time checks, and per‑day bitmaps for analytics and operational statistics. Using BITOP AND on 30 per‑day keys would require ~3.5 GB of data and block the single‑threaded Redis for hundreds of milliseconds, so it is avoided in production.

Redis persistence is simple: SETBIT sign:{uid}:{year} {day_of_year} 1 to record a sign‑in, and GET sign:{uid}:{year} to retrieve the whole year’s bitmap for local processing. Crossing a year boundary is handled by reading two keys and concatenating the bits.

The article also lists common wrong answers (e.g., storing each sign‑in as a MySQL row, using Redis List/Set, relying on BITCOUNT, performing BITOP AND online, or only storing per‑day bitmaps) and explains why they fail.

Typical follow‑up questions and concise answers are provided, covering cumulative counts, sparsity, idempotent reward issuance, and extreme memory constraints.

Finally, a five‑step interview answer template is given, covering selection of bitmap, key dimension, avoiding BITCOUNT, local algorithm, and engineering closure (dual storage, cross‑year handling, idempotent reward key).