Truecaller Caller ID and Spam Detection.

How Do You Name a Stranger Before the Phone Has Finished Ringing?

It is 10:41 on a Tuesday morning in a village outside Gorakhpur. Sunita Yadav, 61, a retired anganwadi supervisor, is drying dal on the roof, where her phone shows one bar of signal on a good day. It rings. The number starts with +91 and isn't one she has saved. A man on the other end, if she answered, would say he is calling from "the telecom department" and that her SIM will be cut off in two hours unless she presses 9.

The number didn't exist as a problem yesterday. It started calling at 9:12 this morning, working down a list. By 10:30, hundreds of people across eastern Uttar Pradesh and Bihar had declined it, and some of them had tapped "Report spam" and typed "Fake TRAI call". Sunita's phone has a list of known spammers that it downloaded last night; this number is not on it. Her network can barely load a web page. Yet before the second ring, her screen turns red: "Likely fraud". She puts the phone face down and goes back to the dal.

At the same moment, in Pune, her son Rohit's iPhone rings with the same number. His phone asks the same question, but through a relay and in encrypted form, so that the company answering it never learns who was asked about which number.

This is the system we'll design today.

The Interview Begins#

You're interviewing at a company that builds a communication-safety app. The interviewer holds up two phones side by side. On the left, an incoming call: a red banner, "Likely fraud · Telecom impersonation · 1,814 reports". On the right, the same screen a minute later on a different phone: a green banner, "Ramesh Kumar · Someone you may know".

Your Questions#

Functional Requirements#

Non-Functional Requirements#

Lookup Traffic#

The Directory#

Reports and Signals#

The Phone#

Key Metrics Summary#

System Architecture#

%% title: Caller ID: a deadline-bound read path, fed by a streaming spam pipeline
flowchart TD
  subgraph L1["Layer 1 · Phones"]
    direction LR
    AND@{ icon: "tech:android", label: "Android app<br/>contacts, spam list, live lookup" }
    IOS@{ icon: "tech:apple", label: "iPhone<br/>Live Caller ID, encrypted" }
  end
  subgraph L2["Layer 2 · Edge"]
    direction LR
    GW@{ icon: "sd:gateway", label: "Regional API edge<br/>auth, rate limits" }
    RELAY@{ icon: "sd:tunnel", label: "Oblivious HTTP relay<br/>run by Apple" }
  end
  subgraph L3["Layer 3 · Read path"]
    direction LR
    LOOK["Lookup service<br/>normalise, resolve, deadline"]:::hot
    PIR["PIR service<br/>encrypted shards in memory"]:::core
    CACHE@{ icon: "tech:redis", label: "Redis<br/>hot serving records" }
  end
  subgraph L4["Layer 4 · Write path"]
    direction LR
    INGEST["Report and signal intake<br/>validate, rate limit"]:::service
    BUS@{ icon: "tech:kafka", label: "Kafka-API log<br/>reports, call outcomes" }
    SCORE["Spam and name scoring<br/>stream plus daily batch"]:::core
  end
  subgraph L5["Layer 5 · State"]
    direction LR
    STORE@{ icon: "tech:cassandra", label: "Number store · Cassandra<br/>serving records, per region" }
    LISTS@{ icon: "sd:object-storage", label: "Spam list builds<br/>daily list, hourly deltas" }
  end
  AND ==> GW ==> LOOK
  IOS ==> RELAY ==> PIR
  LOOK ==> CACHE
  CACHE -.->|"miss"| STORE
  AND -->|"reports, outcomes"| GW
  GW --> INGEST ==> BUS ==> SCORE
  SCORE ==>|"rewrite record"| STORE
  SCORE --> LISTS
  LISTS -.->|"download"| AND
  STORE -.->|"rebuild shards"| PIR
  class AND,IOS client
  class GW,RELAY edge
  class CACHE cache
  class BUS queue
  class STORE,LISTS store

KEY INSIGHTS:

• The phone is the first tier. Contacts and the on-device spam list answer many calls with no network at all; the server is asked only about strangers the phone doesn't already know
• Precompute the answer, fetch it in one read. Scores and best names are computed on the write path and stored as one small serving record per number, so a lookup is a key read with a deadline, never a query
• Two read paths, one truth. Android asks the lookup service in the clear over TLS; iPhone asks a PIR service through a relay. Both serve the same records, rebuilt from the same store

Data Flow: Sunita's Call at 10:41#

%% title: Sunita's call at 10:41, on one bar of signal
sequenceDiagram
  autonumber
  participant P as Sunita's phone
  participant L as On-device list
  participant E as Regional edge
  participant S as Lookup service
  participant C as Hot cache
  P->>P: Not in contacts
  P->>L: In last night's spam list?
  L-->>P: No
  P->>E: Look up number, deadline 800 ms
  E->>S: Token valid, under rate limit
  S->>C: Serving record for this number
  C-->>S: Likely fraud, 1,814 reports, rewritten 10:22
  S-->>P: Verdict, about 140 bytes
  P->>P: Red screen before the second ring

MEANWHILE, IN PARALLEL:

• Since 9:12, every decline, block and report of this number has flowed through the intake into the log; at 10:22 its score crossed the fraud threshold and the scorer rewrote its serving record in every region
• At 10:30 the region's hourly delta included it; Sunita's phone hadn't fetched it yet, which is why the live lookup mattered
• Her unanswered call becomes one more signal: another vote

Deep Dive 1: The Lookup Path in Milliseconds (Week 1 Concepts: Partitioning, Replication; Week 4: Multi-Tier Caching)#

This builds on Week 1, Day 1 · Partitioning Deep Dive, Week 1, Day 2 · Replication Trade-offs and Week 4, Day 5 · Multi-Tier Caching.

What is published: Truecaller hasn't published its Android lookup path. It has said that EU users' data is processed in data centres in Sweden and that Indian user data is stored in India (Truecaller, October 2022); its Kafka pipeline ran in two regions with the most critical one in Asia (Redpanda case study); and its job listings name Google Cloud, Kubernetes, Cassandra, ScyllaDB, Redis and Aerospike. For iPhone, its engineers wrote that keeping "all shard data in memory" avoids expensive disk reads and makes the lookup CPU-bound (Truecaller Engineering, June 2025). It launched Truecaller Lite in early 2026 for low-end devices "with less reliable connectivity" (Truecaller interim report, May 2026).

%% title: Five tiers, each answering what it can within the ring
flowchart TD
  CALL@{ icon: "sd:phone", label: "Incoming call<br/>number normalised to E.164" }
  CON["Contacts on the phone<br/>a saved name wins"]:::service
  DEV["On-device spam list<br/>region, refreshed daily"]:::service
  EDGE@{ icon: "sd:cache", label: "Lookup pod memory<br/>seconds-long TTL" }
  HOT@{ icon: "tech:redis", label: "Redis<br/>hot records, ~45 GB" }
  DB@{ icon: "tech:cassandra", label: "Cassandra<br/>all records, local replica" }
  CALL ==> CON
  CON -->|"unknown"| DEV
  DEV -->|"not listed"| EDGE
  EDGE -->|"miss"| HOT
  HOT -.->|"miss"| DB
  class CALL client
  class EDGE,HOT cache
  class DB store

• The serving record is the product. Per number: display name, category, spam band, report count, verified flag, version, timestamp. Name candidates, report text and history live in tables the call path never touches.
• Hash partitions, local replicas. A few thousand virtual nodes per region; each record is one row, read from one local replica. The scorer writes each new version to every region allowed to serve it (spam verdicts everywhere; names only inside their jurisdiction, Deep Dive 6), and a newer version always wins, so out-of-order replication can't resurrect an old verdict.
• Most lookups never reach the store. Pod memory absorbs repeats within seconds, Redis holds the hot set, Cassandra serves the long tail; "no record" is cached too, for a few minutes.
• Budget the ring. Contacts and the device list: under 20 ms. Network: about 800 ms, of which the server gets under 30 ms. The rest belongs to a sleepy radio on one bar, which is why there is only one round trip.

# lookup/resolve.py

"""
Resolving an incoming number on the phone (illustrative). Each tier answers what
it can; the network is asked once, with a deadline, and a late answer may still
update the ringing screen.
"""

import hashlib

DEADLINE_MS = 800


def key(e164: str) -> bytes:
    return hashlib.sha256(e164.encode()).digest()[:8]       # the same 8-byte hash the device list uses


def resolve(number: str, sim_country: str, phone, net) -> dict:
    e164 = phone.normalise(number, sim_country)               # "098..." and "+91 98..." become one key
    if (name := phone.contacts.get(e164)) is not None:
        return {"name": name, "source": "contacts"}            # a saved name always wins
    local = phone.spam_list.get(key(e164))                     # last daily list plus hourly deltas
    if local is not None and local.blocking:
        return {"verdict": local.category, "source": "device"}
    fut = net.lookup_async(e164, token=phone.token(), timeout_ms=DEADLINE_MS)
    phone.screen.on_late_answer(fut)                           # repaint if it lands while ringing
    answer = fut.result_or_none(DEADLINE_MS)
    if answer is not None:
        return answer                                          # name, category, score band, reports
    if local is not None:
        return {"verdict": local.category, "source": "device"}
    return {"name": None, "source": "unknown"}                 # still better than guessing

Deep Dive 2: Hot Numbers: When Every Phone Asks About the Same Scam (Week 1 Concepts: Hot Keys and Skew; Week 4: Thundering Herd)#

This builds on Week 1, Day 4 · Hot Keys and Skew, Week 4, Day 1 · Caching Patterns and Week 4, Day 3 · Thundering Herd.

What is published: Truecaller says it updates its spam lists daily "because spammers change their numbers frequently" (Truecaller CNAP comparison page), that its lists are specific to the user's region, and that it shows spam statistics per number: where it calls from, the time of day it's most active, how often it has been reported and "the number of spam calls made over 60 days" (Truecaller spam-blocking page). Its privacy policy lists "the velocity and frequency of communication of a given number with our Users" among the signals it processes (Truecaller privacy policy, July 2026). How its caches handle hot numbers isn't published.

• Heat and spam are the same measurement: calls per number per minute feeds both the scorer and the cache planner.
• Two kinds of hot numbers. A scam number is hot for hours and changes often; a bank's number is hot for years and rarely changes, so give it a long TTL and ship it to phones in a verified-business list.
• Write-through with versions. A stale write (42 after 43) is ignored everywhere; pod caches expire in seconds.
• Watch the skew, not the average: the hottest Redis node's load against the median; above about 3× a hot key escaped detection.

# lookup/hot.py

"""
Hot numbers (illustrative). Records the pipeline flags as hot are written as
several copies on different nodes; readers pick one at random. Updates overwrite
every copy with a newer version, so a verdict change never creates a miss.
"""

import random

COPIES = 8


def read(redis, store, flight, k: str, hot: bool):
    rk = f"{k}#{random.randrange(COPIES)}" if hot else k
    rec = redis.get(rk)
    if rec is not None:
        return rec
    return flight.do(k, lambda: store.get(k))                # single-flight: one store read per pod per miss


def write(redis, store, k: str, rec, hot: bool):
    store.put_if_newer(k, rec, version=rec.version)
    for rk in ([f"{k}#{i}" for i in range(COPIES)] if hot else [k]):
        redis.set_if_newer(rk, rec, version=rec.version)     # overwrite, never delete: no miss to stampede

Deep Dive 3: Names and Spam Scores From the Crowd (Week 8 Concepts: Event Ingestion, Streaming vs Batch; Week 1: Rate Limiting)#

This builds on Week 8, Day 1 · Event Ingestion, Week 8, Day 2 · Streaming vs Batch Processing and Week 1, Day 3 · Rate Limiting at Scale.

What is published: Truecaller's 2022 explainer says names come from user profiles, "public partnerships" and community suggestions, and that "if an insurance spam number is saved or reported as 'Insurance spam' by the maximum number of our users, then that is what the caller ID will show". Its CNAP comparison page says a number is marked "Likely important" when people generally answer it. Its privacy policy lists "number longevity" and "trust/reputation signals", and, for numbers of people who don't use the app, "the velocity and frequency of communication of a given number with our Users" (July 2026). In 2024 Kunal Dua, its vice president of search, told TechCrunch that Truecaller had tested "multiple dozen algorithms" to identify spam, each also learning from user feedback, and that some legitimate businesses may be blocked temporarily "before our community, and before our AI algorithms can identify that this is a legitimate business". A Redpanda case study says spam analytics rely on the real-time pipeline, which moved from self-managed Kafka to Redpanda, cutting infrastructure cost by 58% and latency by almost half.

%% title: From a report or a declined call to a new verdict in minutes
flowchart TD
  APP@{ icon: "sd:phone", label: "Phone<br/>report, decline, block, answer" }
  IN["Intake<br/>call-log proof, per-user token bucket"]:::service
  LOG@{ icon: "tech:kafka", label: "Kafka-API log<br/>partitioned by number" }
  WIN["Stream windows<br/>1 h and 24 h per number"]:::core
  SCORE["Scorer<br/>weighted evidence, bands"]:::hot
  BQ@{ icon: "tech:bigquery", label: "BigQuery<br/>daily features, retraining" }
  OUT@{ icon: "sd:database", label: "Serving records<br/>new version per change" }
  APP ==> IN ==> LOG ==> WIN ==> SCORE
  LOG --> BQ
  BQ -.->|"model and reporter trust, daily"| SCORE
  SCORE ==> OUT
  class APP client
  class LOG queue
  class BQ service
  class OUT store

• Partition the log by the reported number, so one stream task keeps each number's windows: distinct callees, declines, reports and call lengths over the last hour and day.
• Events carry proof. A report includes the call event it refers to; the intake checks the device's outcome stream has that call. Reports about calls that never happened never reach the log.
• Weights from the batch, scores from the stream. A daily job over the full history recomputes each reporter's trust (agreement with final verdicts, account age, verification) and retrains the model; the stream applies them to the last hour. Distinct reporters count, not reports, and no reporter's influence on one number is unbounded.
• Bands with hysteresis, so a verdict doesn't flicker between calls; "Likely fraud" needs fraud-category reports from trusted reporters.
• Names follow the same pattern. The owner's own profile (final once verified) beats verified business records, which beat community suggestions weighted by trust and recency. When a recycled number gets a new owner, old candidates stop counting. Overrides by verified owners or businesses are explicit, versioned and logged.

# spam/score.py

"""
Scoring a number from one hour of evidence (illustrative). Reports count once per
distinct reporter, weighted by that reporter's trust from the daily batch; call
outcomes carry as much weight as reports; verified owners set a floor.
"""

import math

BANDS = [(0.85, "LIKELY_FRAUD"), (0.65, "LIKELY_SPAM"), (0.40, "SUSPECTED_SPAM")]
STEP_DOWN = 0.10                                   # hysteresis: must fall this far below a band to leave it


def score(win, trust: dict, model) -> float:
    reporters = {r.user: r for r in win.reports if r.has_call_proof}
    report_weight = sum(min(trust.get(u, 0.05), 1.0) for u in reporters)
    features = {
        "reports": math.log1p(report_weight),
        "fraud_share": sum(r.category == "fraud" for r in reporters.values()) / max(len(reporters), 1),
        "distinct_callees": math.log1p(win.distinct_callees),
        "decline_rate": win.declined / max(win.calls, 1),
        "short_call_rate": win.short_calls / max(win.answered, 1),
        "saved_by_callees": win.callees_with_number_saved / max(win.distinct_callees, 1),
        "number_age_days": win.number_age_days,
    }
    return model.predict(features)                 # retrained daily on verdicts users confirmed or undid


def band(prev: str, s: float, verified_owner: bool) -> str:
    if verified_owner:
        return "NOT_SPAM"                          # a dispute upheld after verification overrides the crowd
    for threshold, name in BANDS:
        if s >= threshold:
            return name
        if prev == name and s >= threshold - STEP_DOWN:
            return name                            # stay put: no flicker between calls
    return "NONE"

Rate limits that hold across many pods#

What is published: Truecaller's ad server has the mirror-image problem: many pods calling partners that each allow a fixed rate, at peaks of over 600,000 requests a second. A shared limiter in Redis would add "additional network calls and latency", so each pod runs a token bucket (Resilience4j's RateLimiter) set to the partner's limit divided by the number of pods, recalculated when the Kubernetes autoscaler changes the pod count, which pods learn through the Kubernetes Watch API (Truecaller Engineering, February 2025).

• Global caps, split locally: "at most 2,000 report events a second about any one number" becomes 2,000 ÷ N per pod, recomputed when N changes; no shared counter on the hot path.
• Per-user caps need per-user state: a reporter's daily cap and a searcher's hourly cap live in a small store sharded by user, so there's no hot key.
• Scraping is read-path abuse. Cap manual searches per account and device, require a verified number to register, and score accounts whose searches walk number ranges in order. Caller ID for real incoming calls is unaffected.

# limits/per_pod.py

"""
A global rate split across pods (illustrative), as Truecaller described for its
ad server: each pod gets limit / N tokens a second, and N is updated from
Kubernetes watch events when the autoscaler adds or removes pods.
"""

import time


class PodBucket:
    def __init__(self, global_qps: float, pods: int):
        self.global_qps = global_qps
        self.set_pods(pods)
        self.tokens, self.t = self.rate, time.monotonic()

    def set_pods(self, pods: int):                      # called from the watch on scale events
        self.rate = self.global_qps / max(pods, 1)      # 150,000 / 3 = 50,000; / 4 = 37,500

    def try_acquire(self) -> bool:
        now = time.monotonic()
        self.tokens = min(self.rate, self.tokens + (now - self.t) * self.rate)
        self.t = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False                                    # timeout 0: reject now, don't queue

Deep Dive 4: Offline and on One Bar: The Phone as a Cache (Week 4 Concepts: Multi-Tier Caching, Cache Invalidation)#

This builds on Week 4, Day 5 · Multi-Tier Caching and Week 4, Day 2 · Cache Invalidation.

What is published: Truecaller says it "refreshes its spam lists daily to block calls from the most notorious spammers in your area", that Premium users get the list updated automatically while free users update it by hand, and that a phone without an updated list still shows a red caller ID for a spam call (Truecaller spam-blocking page). Its iPhone history shows the limits of offline lists: Apple's Call Directory Extension (2016) preloaded numbers but had little memory, could "crash or silently fail", had "a hard cap on the number of entries", and was refreshed in the background so rarely for infrequent users that data "could quickly become stale"; Truecaller split its numbers across several extensions to raise the cap (Truecaller Engineering, June 2025). In early 2026 it launched Truecaller Lite for low-end devices with less reliable connectivity (Truecaller, May 2026).

%% title: The spam list, from the nightly build to a phone that was offline for three days
flowchart TD
  SC["Scorer<br/>verdict changes all day"]:::core
  BUILD@{ icon: "sd:cron", label: "List builder<br/>nightly base, hourly deltas" }
  CDN@{ icon: "sd:cdn", label: "CDN<br/>signed files per region and version" }
  PUSH@{ icon: "tech:firebase", label: "FCM tickle<br/>urgent delta ready" }
  PH@{ icon: "sd:phone", label: "Phone<br/>base 900 plus deltas" }
  OLD{"More than 7 days behind?"}
  SC ==> BUILD ==> CDN
  BUILD -.-> PUSH -.-> PH
  PH ==> OLD
  OLD -->|"no: deltas in order"| CDN
  OLD -->|"yes: fresh base"| CDN
  class BUILD service
  class CDN edge
  class PUSH external
  class PH client

• Regional, not global. A list per region (a telecom circle, say) keeps it small: today's UP East scam is in the UP East delta, not Kerala's.
• Hashes for size, not secrecy. Indian mobile numbers are a small space, so a hash can be reversed by brute force; 8-byte hashes are just compact. The list holds only spam numbers, never names.
• Fetch on the user's terms. Bases on Wi-Fi or while charging; deltas of a few kilobytes on mobile data; a silent push tells a region an urgent delta exists, and phones fetch it with jitter.
• The device list blocks; the server explains. A list hit can block at once; a live answer, if it arrives, adds name, category and evidence. Settings show "spam list updated 3 days ago": staleness is visible, not silent.

# device/spamlist.py

"""
The on-device spam list (illustrative): sorted 8-byte hashes with a category,
a version, and signed deltas applied in order; a phone too far behind fetches a
fresh base. Lookups are a binary search.
"""

import bisect

MAX_DELTA_GAP = 7 * 24                          # hourly deltas are kept for 7 days


def get(lst, h: bytes):
    i = bisect.bisect_left(lst.keys, h)
    return lst.cats[i] if i < len(lst.keys) and lst.keys[i] == h else None


def sync(phone, cdn, region: str):
    if cdn.latest_version(region) - phone.spam_list.version > MAX_DELTA_GAP:
        phone.spam_list = cdn.base(region)                     # too far behind: start again
    for d in cdn.deltas(region, after=phone.spam_list.version):
        if d.from_version != phone.spam_list.version or not d.signature_ok():
            break                                              # retry later, never half-apply
        phone.spam_list.remove_all(d.removes)                  # clearings first: a wrong red label is our harm
        phone.spam_list.upsert_all(d.adds)
        phone.spam_list.version = d.to_version

Deep Dive 5: Private Lookups on iPhone: Answering Without Knowing the Question (Week 9 Concepts: Security Architecture; Week 1: Rate Limiting)#

This builds on Week 9, Day 5 · Security Architecture and Week 1, Day 3 · Rate Limiting at Scale.

What is published: Truecaller's engineers described the path (June 2025). After years of workarounds (copy and paste in 2009, a preloaded directory in 2016, a Siri shortcut reading the call screen with OCR in 2023), iOS 18's Live Caller ID Lookup changed things. Queries arrive through an Oblivious HTTP relay (RFC 9458), so "all incoming queries look identical"; the app issues "a set of single-use tokens to authenticated users" (Privacy Pass, RFC 9578), and the backend checks a token is genuine and unused but "cannot trace the token back to any specific user". The database is split into shards (8 in their example) and buckets (21); the client sends an encrypted bitmask and the server returns an encrypted dot product with the shard. iOS sends "two requests: one for blocking and one for identity" on every call; the block answer is one bit and must come "before the phone even rings". With shards in memory, "sub-100ms latency becomes a realistic goal". All Truecaller learns is that "a Truecaller user" queried something "possibly in shard 3".

%% title: Rohit's iPhone asks, and Truecaller never learns who asked about what
sequenceDiagram
  autonumber
  participant A as Truecaller app
  participant I as Rohit's iPhone
  participant R as Apple's relay
  participant T as PIR service
  A->>T: Signed in, fetch a batch of single-use tokens
  Note over I: later, a call from an unknown number
  I->>I: Number maps to shard 3, bucket 11
  I->>R: Block query, encrypted selector, token 1
  I->>R: Identity query, encrypted selector, token 2
  R->>T: Both queries, without Rohit's IP or device
  T->>T: Tokens genuine and unspent, dot product over shard 3
  T-->>R: Encrypted results
  R-->>I: Relayed back
  I->>I: Decrypt, find the number in bucket 11, block or show the name

• Two databases, two cadences (our design): a small block database (one bit per number) rebuilt with the hourly deltas, and a larger identity database rebuilt less often, both from the Android path's serving records, loaded beside the old version and switched atomically.
• Shard size is a budget: big enough that "shard 3" says almost nothing, small enough that one core answers well inside the ring.
• Rate limiting without identity: cap tokens per account per day at issue; keep a set of spent token IDs per key epoch and reject repeats.
• Capacity is CPU, doubled: two homomorphic queries per call over a full shard. Plan cores, with headroom; a slow block bit is a call that rings when it shouldn't.

# pir/toy.py

"""
The idea behind the private lookup (illustrative, in the clear). The real system
encrypts the selector with homomorphic encryption (Apple's swift-homomorphic-
encryption), so the server computes the same dot product without seeing which
bucket is selected.
"""

import hashlib

SHARDS, BUCKETS = 8, 21                       # the worked example in Truecaller's post


def place(e164: str) -> tuple:
    h = int.from_bytes(hashlib.sha256(e164.encode()).digest()[:8], "big")
    return h % SHARDS, (h // SHARDS) % BUCKETS  # deterministic: client and server agree


def client_query(e164: str):
    shard, bucket = place(e164)
    selector = [1 if b == bucket else 0 for b in range(BUCKETS)]
    return shard, encrypt(selector)            # the shard index is visible, the bucket is not


def server_answer(shards, shard: int, enc_selector):
    rows = shards[shard]                       # every bucket of the shard, held in memory
    return sum_encrypted(enc_selector[b] * rows[b] for b in range(BUCKETS))  # touches the whole shard


def client_read(e164: str, enc_answer):
    bucket_records = decrypt(enc_answer)       # all records in bucket 11
    return next((r for r in bucket_records if r.number == e164), None)

Deep Dive 6: Whose Data Is It? Contacts, Consent and Where Data Lives (Week 9 Concepts: Tenant Isolation, Data Residency, Right to Deletion)#

This builds on Week 9, Day 1 · Tenant Isolation, Week 9, Day 3 · Data Residency and Week 9, Day 4 · Right to Deletion.

What is published: Truecaller says its store apps don't upload phonebooks "to make them searchable or public" (2022) and that it reads contacts "only on your device" and does "not upload your contacts" (2026); that names come from "suggestions made by other users within the app"; that profiles are private to name searches by default; and that an unlisted number leaves search "within 24 hours", except numbers "marked as spam or fraud by the community". In October 2022 it described "Enhanced Search" as an option for non-EU users "to share data on a consent basis", said EU-originated data is "automatically rejected", that EU users' data is processed in Sweden and that "Indian user data is stored in India". Its privacy policy (3 July 2026) says a user who shares someone else's information confirms they "are aware" and "consent", and that it may process information about non-users' numbers "that we receive from our Users" to derive trust signals.

What critics and courts have said: in 2022, Rest of World published an investigation by The Caravan that reported, from interviews including a former employee, that much of the database came from users' contact lists, including pre-installed apps with Enhanced Search on by default, without the named people's consent; in written responses quoted there, Truecaller said it offers a "privacy-focused service" that is "committed to being transparent and compliant with the laws of the countries we operate in". On 14 September 2026, the Lagos State High Court held, in a case brought for Nigerian non-users, that "Consent to one does not equate to consent to the other", but dismissed the application because the applicants hadn't proved by credible evidence that their rights were infringed; the judge also noted that Truecaller had deleted the applicants' numbers when they asked. Truecaller's lawyers said nothing is uploaded unless a user takes a separate voluntary step, such as installing a version from outside the Google and Apple stores, and that data is processed in India under the DPDP Act (ICIR, September 2026).

The law in India: the DPDP Act was enacted on 11 August 2023 and its Rules notified on 14 November 2025, with an 18-month phased compliance period; consent must be clear and informed and can be withdrawn, rights requests must be answered within 90 days, and failing to keep reasonable security safeguards can cost up to ₹250 crore (PIB, November 2025). As the bill was being passed, Truecaller's then CEO Alan Mamedi said it would "comply with all provisions" and that the law "will not affect the user experience in any significant manner" (Truecaller, August 2023).

%% title: A number's listing, from first call to unlisted
stateDiagram-v2
  [*] --> UNKNOWN: first seen in a call
  UNKNOWN --> COMMUNITY_NAMED: trusted suggestions agree
  UNKNOWN --> REGISTERED: owner signs up and verifies
  COMMUNITY_NAMED --> REGISTERED: owner signs up
  UNKNOWN --> SPAM_FLAGGED: score crosses a band
  COMMUNITY_NAMED --> SPAM_FLAGGED: score crosses a band
  SPAM_FLAGGED --> UNKNOWN: verdict cleared or disputed
  SPAM_FLAGGED --> SPAM_FLAGGED: unlist refused
  COMMUNITY_NAMED --> UNLISTED: owner unlists
  REGISTERED --> UNLISTED: owner deletes and unlists
  REGISTERED --> UNKNOWN: number recycled
  UNLISTED --> [*]
  class REGISTERED ok
  class UNLISTED ok
  class SPAM_FLAGGED bad
  class COMMUNITY_NAMED queue

• Lineage on every name candidate: source, basis, region, date. The shown name is a function of the candidates and a policy table, so a change in law is a table change and a recompute.
• Jurisdiction as the tenant: personal data partitioned by where it was collected (EU in Sweden, India in India), with separate pipelines and keys; only spam verdicts and verified-business records cross, decided per field.
• Minimise where it's cheap: no names in device lists, SMS spam detection on the phone (Truecaller says SMS content doesn't reach its servers unless shared as feedback), iPhone queries never readable by the server.
• Deletion is a fan-out with a deadline: a tombstone version, overwritten caches, rebuilt PIR shards, candidates deleted from the store and analytics tables, and a log proving each step met the 24-hour promise.
• Let consented sources win, the owner's own name and verified businesses over crowd suggestions: the direction both the DPDP Act's consent rules and the Lagos court's reasoning point. Keep name-to-number search off.

# names/serving_name.py

"""
Choosing the name to show for a number (illustrative). Every candidate carries
its source, basis and region; a per-jurisdiction policy decides which sources may
be shown. Unlisting and recycling are tombstones, not deletions-in-place.
"""

WEIGHT = {"owner_profile": 100.0, "verified_business": 80.0, "community": 1.0}


def serving_name(number, candidates, policy, listing):
    if listing.state == "UNLISTED":
        return None                                     # tombstone (spam-flagged numbers can't be unlisted)
    allowed = policy.allowed_sources(number.jurisdiction)   # e.g. {"owner_profile", "verified_business"}
    votes = {}
    for c in candidates:
        if c.source not in allowed or c.collected_at < listing.owner_since:
            continue                                    # disallowed source, or about the previous owner
        w = WEIGHT[c.source] * c.reporter_trust * c.recency
        votes[c.name] = votes.get(c.name, 0.0) + w
    if not votes:
        return None
    return max(votes, key=votes.get)

One Scam Number's Morning#

Edge Cases#

Monitoring Dashboard#

SLOs for the Platform#

The interviewer leans back. "One more."

Summary: Concepts Applied from 10-Week Course#

Why Truecaller Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

The read path:

The write path:

The phone and privacy:

Sources#

Truecaller:

• Blog

  Ahmed Alnaqah — How We Made Truecaller Finally Work on iPhone (Call Directory Extension limits; OHTTP relay; Privacy Pass tokens; PIR over 8 shards × 21 buckets; two queries per call; sub-100 ms with shards in memory), Truecaller Engineering, 30 June 2025: https://www.truecaller.com/engineering/ios/how-we-made-truecaller-finally-work-on-iphone

• Blog

  Shabbir Goher — Controlling QPS in a Fan-Out Microservice Architecture (ad server peaks over 600,000 requests a second; per-pod token buckets of QPS ÷ N; Kubernetes Watch), Truecaller Engineering, 14 February 2025: https://www.truecaller.com/engineering/backend/controlling-qps-in-a-fan-out-microservice-architecture

• Read

  Truecaller announces preliminary numbers for the third quarter 2026 (average non-iOS MAU 476.2 million and DAU 411.1 million), 19 October 2026: https://mfn.se/cis/a/truecaller/truecaller-ab-truecaller-announces-preliminary-numbers-for-the-third-quarter-2026-c1f4a15d

• Read

  Truecaller interim report January–March 2026 (non-iOS MAU 463.2 million; 500 million+ across iOS and Android; Truecaller Lite for less reliable connectivity), 7 May 2026: https://mfn.se/all/a/truecaller/truecaller-ab-user-and-premium-growth-continue-while-we-strengthen-the-platform-for-the-future-e135255b

• Read

  Truecaller corporate site (500M+ monthly active users; 1B+ installs; 68B+ spam calls identified and blocked in 2025), accessed October 2026: https://corporate.truecaller.com/

• Book

  Truecaller — About us (founded in Stockholm in 2009 by Nami Zarringhalam and Alan Mamedi; listed on Nasdaq Stockholm in October 2021), accessed October 2026: https://www.truecaller.com/about

• Docs

  Truecaller — Spam Blocking (spam lists refreshed daily and specific to the region; automatic updates for Premium, manual for free users; blocking a numbered series; 46.9 billion spam calls identified in 2023), accessed October 2026: https://www.truecaller.com/spam-blocking

• Read

  Truecaller — CNAP vs Truecaller ("Likely important" and "Someone you may know" from call patterns; spam list updated daily "because spammers change their numbers frequently"; number recycling), accessed October 2026: https://www.truecaller.com/cnap-vs-truecaller-understanding-the-differences

• Read

  Truecaller — Facts and Insights (contacts accessed only on the device, not uploaded; SMS processed on the device), accessed October 2026: https://www.truecaller.com/busting-myths-about-truecaller

• Book

  Truecaller — Privacy Center (profiles private to name searches by default; contact requests; unlisting unless identified as a spammer), accessed October 2026: https://www.truecaller.com/privacy/privacy-center

• Read

  Truecaller — Privacy Policy (consent for information about others; signals about non-users' numbers received from users; number longevity and trust signals), last updated 3 July 2026: https://www.truecaller.com/privacy-policy

• Blog

  Anaida Sen — How Truecaller's Caller ID Works: Your Questions Answered (37.8 billion spam calls in 2021; names from profiles, public partnerships and community suggestions; the most-used label wins), Truecaller Blog, 13 June 2022: https://www.truecaller.com/blog/features/how-truecallers-caller-id-works-your-questions-answered

• Paper

  Truecaller — Update on recent inquiries from investors and media (Enhanced Search an option for non-EU users on a consent basis; EU-originated data rejected), 3 October 2022: https://mb.cision.com/Main/20429/3641129/1633543.pdf

• Read

  Truecaller — Truecaller statement in relation to new data privacy regulations in India (Alan Mamedi on the DPDP Bill), 8 August 2023: https://news.cision.com/truecaller-ab/r/truecaller-statement-in-relation-to-new-data-privacy-regulations-in-india,c3814927

• Read

  Truecaller job listings (Google Cloud, Kubernetes, Cassandra, ScyllaDB, Redis, Aerospike, Kafka, BigQuery; Go and Scala), Greenhouse, October 2026: https://job-boards.greenhouse.io/truecaller

Industry:

• Read

  Redpanda — Truecaller halves costs and latency with Redpanda (Kafka clusters in two regions with the most critical in Asia; spam analytics depend on the pipeline), customer case study: https://redpanda.com/case-study/truecaller

Reporting:

• Read

  Digital Terminal — Truecaller Surpasses 500 Million Global Users (350 million+ in India, 150 million outside; 50 million+ added in 2025; about 470 employees), 1 April 2026: https://digitalterminal.in/infotainment/truecaller-surpasses-500-million-global-users-built-with-india-at-its-core

• Read

  ETV Bharat — India Ranked Fifth Most Spammed Country In The World, Truecaller Report Reveals (68 billion+ spam and fraud calls identified in 2025; India fifth), 6 May 2026: https://www.etvbharat.com/en/technology/india-ranked-fifth-most-spammed-country-in-the-world-truecaller-report-reveals-enn26050604266

• Read

  Jagmeet Singh — Truecaller adds a new AI feature to detect and block more spam calls (Max; "multiple dozen algorithms"; Kunal Dua on temporary blocking of legitimate businesses), TechCrunch, 18 March 2024: https://techcrunch.com/2024/03/18/truecaller-automatically-reject-all-spam-calls-android-update

• Docs

  Rachna Khaira (The Caravan) — How TrueCaller built a billion-dollar caller ID data empire in India (5.7 billion phone identities per the prospectus; criticism of contact-based data collection and Enhanced Search; Truecaller's written responses), Rest of World, 8 March 2022: https://restofworld.org/2022/how-truecaller-built-a-billion-dollar-id-data-empire-in-india/

• Read

  Marcus Fatunmole — Truecaller: Court rejects users' consent for processing non-users' phone numbers (Lagos State High Court ruling of 14 September 2026; application dismissed because infringement wasn't proved; applicants' numbers deleted on request; Truecaller's counter-affidavit), ICIR, 22 September 2026: https://www.icirnigeria.org/truecaller-court-rejects-users-consent-for-processing-non-users-phone-numbers/

• Book

  Shrishti Bisht — Centre Directs Telcos To Display Caller Names From November 1 (CNAP on 4G and higher by default from 1 November 2026; originating operator's name database), Inc42, 15 October 2026: https://inc42.com/buzz/centre-directs-telcos-to-display-caller-names-from-november-1/

Law and standards:

• Paper

  Press Information Bureau — DPDP Rules, 2025 Notified (Act enacted 11 August 2023; Rules notified 14 November 2025; 18-month phased compliance), 17 November 2025: https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf

• Docs

  RFC 9458 — Oblivious HTTP: https://www.rfc-editor.org/rfc/rfc9458

• Docs

  RFC 9578 — Privacy Pass Issuance Protocols: https://www.rfc-editor.org/rfc/rfc9578

Design note: the Android lookup path, the cache and store design, the scoring features, bands and code, the list format, the PIR database cadences, the lineage scheme, the dashboards and every number labelled as an assumption or estimate are an illustrative design for the problem, not a description of Truecaller's internal systems beyond what Truecaller and the sources above have published. Calls per user, the share from unknown numbers, report rates, record sizes, list sizes and the festival-week figures are assumptions. Sunita, Rohit and Kavya are fictional. Legal and regulatory points are summarised for engineering context, are not legal advice, and should be checked against current law.

Further Reading#

Related systems to study:

• Read

  Google Maps (Bonus Problem 22 in this series): another product whose users are its sensors, with privacy rules on what they send

• Read

  Aadhaar (Bonus Problem 3): identity, consent and data protection at India's scale

• Read

  WhatsApp (Bonus Problem 2): the phone number as an identity, and end-to-end encryption as a design constraint

• Read

  UPI (Bonus Problem 1): fraud at the other end of the scam call

Course material:

• Talk

  The course's Week 9 capstone (a multi-tenant SaaS) covers isolation, residency and deletion in a business setting

Foundational concepts (this course):

• Read

  Week 1, Day 1 — Partitioning Deep Dive

• Read

  Week 1, Day 2 — Replication Trade-offs

• Read

  Week 1, Day 3 — Rate Limiting at Scale

• Read

  Week 1, Day 4 — Hot Keys and Skew

• Read

  Week 4, Day 1 — Caching Patterns

• Read

  Week 4, Day 2 — Cache Invalidation

• Read

  Week 4, Day 3 — Thundering Herd

• Read

  Week 4, Day 5 — Multi-Tier Caching

• Read

  Week 8, Day 1 — Event Ingestion

• Read

  Week 8, Day 2 — Streaming vs Batch Processing

• Read

  Week 9, Day 1 — Tenant Isolation

• Read

  Week 9, Day 3 — Data Residency

• Read

  Week 9, Day 4 — Right to Deletion

• Read

  Week 9, Day 5 — Security Architecture

"Precompute the verdict, carry the worst numbers on the phone, and keep every name's origin, so the answer arrives before the second ring and can be taken back when it should be."