Bonus Problem 3: Aadhaar (UIDAI)
The World's Largest Biometric Identity System
🪪 Identity at Billion Scale
Imagine this challenge: You need to uniquely identify 1.4 billion people.
Not just assign them a number — but guarantee that each person appears exactly once in your system. No duplicates. No fakes. Every identity verifiable in under 200 milliseconds.
You'll need to match billions of fingerprints against billions of other fingerprints. Trillions of biometric comparisons. Every single day.
This is Aadhaar — and it's the largest biometric identity system ever built.
THE AADHAAR SCALE (2025)
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ ENROLLMENT │
│ ────────── │
│ Total Enrolled: 1.38+ Billion people │
│ Coverage: 99.9% of adult Indian population │
│ Biometric Data: ~15 Petabytes │
│ (10 fingerprints + 2 iris scans + photo per person) │
│ │
│ AUTHENTICATION │
│ ────────────── │
│ Daily Authentications: 90+ Million │
│ Monthly Authentications: 2.5+ Billion │
│ Cumulative (to date): 150+ Billion authentications │
│ e-KYC Transactions: 45+ Million/month │
│ Face Authentication: 18+ Million/month (AI-powered) │
│ │
│ PERFORMANCE │
│ ─────────── │
│ Authentication Latency: < 200ms │
│ Availability: 99.9%+ │
│ Active Entities (AUAs): 550+ │
│ │
│ DEDUPLICATION │
│ ───────────── │
│ Biometric Matches/Day: 600+ Trillion (at peak) │
│ ABIS Vendors: 3 (for redundancy) │
│ Duplicate Detection: 99.965% accuracy │
│ │
│ IMPACT │
│ ────── │
│ DBT Savings: ₹3.5+ Lakh Crore ($42B+) saved │
│ Ghost Beneficiaries: Millions eliminated │
│ Bank Accounts Linked: 788+ Million │
│ │
└─────────────────────────────────────────────────────────────────────────┘
This is the system we'll design today — and understand the engineering marvel behind proving "you are you" at planetary scale.
The Interview Begins
You're interviewing at a government technology agency. The Chief Architect draws on the whiteboard:
Interviewer: "India's Aadhaar is often cited as the world's most ambitious digital identity project. I want you to design a biometric identity system that can scale to a billion people. Walk me through how you'd approach it."
╔═════════════════════════════════════════════════════════════════════════╗
║ ║
║ Design a National Biometric Identity System ║
║ ║
║ Build an identity system that can: ║
║ ║
║ Requirements: ║
║ • Enroll 1+ billion residents with biometrics ║
║ • Guarantee uniqueness (no duplicates in the system) ║
║ • Authenticate identity in real-time (< 500ms) ║
║ • Handle 100+ million authentications per day ║
║ • Work across 640,000 villages with unreliable connectivity ║
║ • Protect biometric data with highest security ║
║ • Provide e-KYC (Know Your Customer) service ║
║ • Support multiple authentication modes (fingerprint, iris, OTP) ║
║ • 99.9%+ availability ║
║ ║
║ Constraint: This is a government project with vendor neutrality ║
║ ║
╚═════════════════════════════════════════════════════════════════════════╝
Interviewer: "The uniqueness guarantee is the hardest part. You need to prove that each of 1.4 billion people appears exactly once. That's never been done before at this scale."
Phase 1: Requirements Clarification
You: "Let me understand the specific challenges before designing."
Your Questions
You: "First, what biometric modalities are we capturing? And what's the expected quality given enrollment happens in remote villages?"
Interviewer: "10 fingerprints, 2 iris scans, and a photograph. Quality will vary — many manual laborers have worn fingerprints, elderly may have faded prints, some people lack fingers. The system must handle all cases."
You: "For uniqueness, what's the acceptable error rate? False accepts (enrolling duplicates) vs false rejects (wrongly rejecting unique people)?"
Interviewer: "This is critical. A false accept means someone gets two identities — they can claim benefits twice. A false reject means a legitimate person can't get enrolled. Both are bad, but false accepts are worse for a welfare system."
You: "What about authentication? Is it 1:1 matching (verify this person is who they claim) or 1:N (find this person in the database)?"
Interviewer: "Authentication is always 1:1 — they provide their Aadhaar number plus biometric, we verify it matches the stored data. Deduplication during enrollment is 1:N — we search the entire database to ensure they're not already enrolled."
You: "What infrastructure can we assume in remote areas?"
Interviewer: "Minimal. Many areas have no internet, unreliable power, extreme temperatures. Enrollment must work offline. Authentication needs connectivity but should degrade gracefully."
Requirements Summary
Functional Requirements:
1. ENROLLMENT
• Capture demographics (name, address, DOB, gender)
• Capture biometrics (10 fingerprints, 2 iris, 1 photo)
• Verify supporting documents (proof of identity/address)
• Perform deduplication (1:N match against entire database)
• Generate unique 12-digit Aadhaar number
• Print and mail physical Aadhaar letter
2. AUTHENTICATION
• Demographic authentication (name/address matching)
• Biometric authentication (fingerprint, iris, face)
• OTP authentication (via registered mobile)
• Multi-factor authentication (combinations)
• Return only Yes/No (no PII in response)
3. e-KYC (Know Your Customer)
• Return verified identity data after authentication
• Digitally signed response
• Replace paper-based KYC for banks, telecom, etc.
4. UPDATE
• Demographics update (address, phone, etc.)
• Biometrics update (for degraded prints)
• Document-based or operator-assisted updates
5. PRIVACY FEATURES
• Virtual ID (16-digit temporary alias for Aadhaar)
• Masked Aadhaar (partially hidden number)
• Authentication history (user can see who queried)
Non-Functional Requirements:
SCALE
• 1.4 billion enrolled residents
• 90+ million authentications/day
• Peak: 1000+ authentications/second
• 15+ petabytes of biometric data
LATENCY
• Authentication: < 200ms (1:1 match)
• Deduplication: minutes (1:N against billions)
ACCURACY
• False Positive Identification Rate (FPIR): < 0.0035%
• False Negative Identification Rate (FNIR): < 0.035%
AVAILABILITY
• 99.9%+ uptime
• Geo-distributed for disaster recovery
SECURITY
• 2048-bit PKI encryption
• Data encrypted at rest and in transit
• HSM for key management
• No biometric data leaves CIDR
Phase 2: Back of the Envelope Estimation
You: "Let me work through the numbers to understand the computational challenge."
The Deduplication Challenge
THE IMPOSSIBLE MATH
To guarantee uniqueness, every new enrollment must be
compared against EVERY existing record.
For 1 billion people with 10 fingerprints each:
Fingerprint comparisons for new enrollment:
1,000,000,000 people × 10 fingers = 10 billion templates
If we enroll 1 million new people per day:
1,000,000 × 10 billion = 10,000,000,000,000,000 comparisons/day
= 10 quadrillion matches/day!
At traditional matching speed (100,000 matches/sec):
10^16 / 10^5 = 10^11 seconds
= 3,170 years per day of enrollment!
This is mathematically impossible with brute force.
The Solution: Multi-Modal + Multi-ABIS
MAKING DEDUPLICATION TRACTABLE
1. DEMOGRAPHIC PRE-FILTER
Before biometric matching, filter by:
• Name phonetics
• Date of birth
• Gender
• Geographic region
This reduces search space by 99%+
2. MULTI-MODAL BIOMETRICS
Using fingerprint + iris together:
• Fingerprint alone: 1 in 10^6 uniqueness
• Iris alone: 1 in 10^12 uniqueness
• Combined: 1 in 10^18 uniqueness
The combination allows lower thresholds per modality
3. HIERARCHICAL MATCHING
• First: Fast, approximate match (GPU-accelerated)
• If potential match: Detailed matching
• If still ambiguous: Human adjudication
4. THREE ABIS VENDORS
• Each vendor runs independent deduplication
• Consensus required (2 of 3 agree)
• Different algorithms catch different edge cases
Storage Estimation
BIOMETRIC DATA STORAGE
Per person:
10 fingerprints: ~100KB (10 × 10KB template)
2 iris scans: ~100KB (2 × 50KB template)
1 photograph: ~50KB
Demographics: ~2KB
Metadata: ~5KB
─────────────────────────────
Total per person: ~257KB
For 1.4 billion people:
1.4B × 257KB = 360 TB (templates only)
Raw biometric images (archived):
Per person: ~5MB (high-res captures)
Total: 1.4B × 5MB = 7 PB
With replication (3x):
~20 PB total storage
Authentication Traffic
AUTHENTICATION LOAD
Daily authentications: 90,000,000
Seconds per day: 86,400
Average TPS: ~1,040 auth/second
Peak multiplier: 3x
Peak TPS: ~3,000 auth/second
Each authentication requires:
1. Decrypt request (PKI)
2. Lookup Aadhaar record
3. Biometric 1:1 match
4. Sign response
Time budget: 200ms total
Network: 50ms
Crypto: 30ms
Lookup: 20ms
Match: 100ms
Phase 3: High-Level Architecture
You: "Aadhaar's architecture follows four key principles: openness, linear scalability, strong security, and vendor neutrality."
The Aadhaar Ecosystem
AADHAAR ARCHITECTURE OVERVIEW
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ ENROLLMENT ECOSYSTEM │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Resident │────▶│ Enrollment │────▶│ Registrar │ │
│ │ (Village) │ │ Agency │ │(State Govt) │ │
│ └─────────────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │
│ Encrypted packet Verification │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────┐ │
│ │ CIDR (Central DB) │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ABIS 1 │ │ ABIS 2 │ │ Deduplication │
│ │ └────┬────┘ └────┬────┘ │ │
│ │ └──────┬─────┘ │ │
│ │ ▼ │ │
│ │ ┌─────────┐ │ │
│ │ │ ABIS 3 │ │ 3-way consensus │
│ │ └─────────┘ │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ AUTHENTICATION ECOSYSTEM │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Resident │────▶│ Service │────▶│ AUA │ │
│ │ (at bank, │ │ Point │ │(Auth User │ │
│ │ telecom) │ │ Device │ │ Agency) │ │
│ └─────────────┘ └─────────────┘ └──────┬──────┘ │
│ │ │
│ Encrypted PID │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ ASA │ │
│ │(Auth Service│ │
│ │ Agency) │ │
│ └──────┬──────┘ │
│ │ │
│ Secure leased line │
│ │ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ CIDR │ │
│ │ (1:1 matching) │ │
│ │ │ │
│ │ Returns: Yes/No │ │
│ │ (no PII returned) │ │
│ └───────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Key Components
COMPONENT BREAKDOWN
1. ENROLLMENT CLIENT
• Runs on laptops in villages
• Captures biometrics (certified devices only)
• Works OFFLINE (syncs when connected)
• Encrypts everything at capture time
• Operator + Supervisor biometric signatures
2. REGISTRAR
• State governments, banks, oil companies
• Responsible for enrollment agencies
• First-level quality checks
• Uploads packets to CIDR
3. CIDR (Central Identities Data Repository)
• The "crown jewels" — all biometric data
• Two data centers (Bengaluru + Manesar)
• Active-active configuration
• NEVER exposed to internet directly
• Only UIDAI has access
4. ABIS (Automated Biometric Identification System)
• Three independent vendors (TCS+Neurotechnology, etc.)
• Each runs complete deduplication
• Consensus-based decision
• Vendor-neutral API integration
5. AUA (Authentication User Agency)
• Banks, telecom, insurance companies
• Licensed to use authentication
• Must follow UIDAI security guidelines
• Audited regularly
6. ASA (Authentication Service Agency)
• Secure network intermediary
• Connects AUAs to CIDR
• Dedicated leased lines (not internet)
• 27 licensed ASAs in India
Data Flow: Enrollment
ENROLLMENT FLOW
Resident visits enrollment center with documents
Step 1: CAPTURE
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ Enrollment Station (Offline-capable laptop) │
│ │
│ 1 Operator logs in with biometric │
│ 2 Captures resident's demographics │
│ 3 Scans proof documents (Ration card, Voter ID, etc.) │
│ 4 Captures 10 fingerprints (slaps + thumbs) │
│ 5 Captures 2 iris scans │
│ 6 Captures photograph │
│ 7 Resident reviews and confirms │
│ 8 Operator signs packet biometrically │
│ 9 Supervisor approves (for exceptions) │
│ │
│ Output: Encrypted enrollment packet (3-5 MB) │
│ Contains HMAC for tamper detection │
│ │
└────────────────────────────────────────────────────────────────────────┘
│
▼
Step 2: UPLOAD
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ Registrar Backend │
│ │
│ 1 Receives packets via SFTP or encrypted USB │
│ 2 Validates packet structure and signatures │
│ 3 Queues for CIDR upload │
│ 4 Uploads via secure channel to CIDR │
│ │
└────────────────────────────────────────────────────────────────────────┘
│
▼
Step 3: DEDUPLICATION
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ CIDR Processing │
│ │
│ 1 Decrypt packet (only CIDR can decrypt) │
│ 2 Extract biometric templates │
│ 3 Demographic pre-filter (reduce search space) │
│ 4 Send to ABIS 1, ABIS 2, ABIS 3 in parallel │
│ 5 Each ABIS returns: UNIQUE / DUPLICATE / MANUAL_REVIEW │
│ 6 Consensus: 2 of 3 must agree │
│ 7 If DUPLICATE: Manual adjudication │
│ 8 If UNIQUE: Generate Aadhaar number │
│ 9 Store in database │
│ 10 Queue letter for printing │
│ │
│ Timeline: 3-90 days (depending on duplicates) │
│ │
└────────────────────────────────────────────────────────────────────────┘
│
▼
Step 4: DELIVERY
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ Aadhaar Letter printed and mailed to resident's address │
│ Contains: 12-digit Aadhaar number + QR code │
│ │
└────────────────────────────────────────────────────────────────────────┘
Phase 4: Deep Dives
Deep Dive 1: Biometric Deduplication at Billion Scale
Week 1 concepts: Partitioning, sharding. Week 3 concepts: Async processing.
You: "Deduplication is the hardest problem in Aadhaar. You must compare each new person against 1.4 billion existing records."
THE DEDUPLICATION CHALLENGE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ Without optimization: │
│ │
│ New enrollment: 1 person │
│ Existing database: 1,400,000,000 people │
│ Fingers per person: 10 │
│ Iris per person: 2 │
│ │
│ Fingerprint comparisons: │
│ 10 (new) × 10 (existing) × 1.4B = 140 trillion comparisons │
│ │
│ At 1 million matches/second: 140 million seconds = 4.4 years! │
│ │
│ For 1 million enrollments/day: 4.4 million years of compute/day │
│ │
│ This is impossible. We need smarter approaches. │
│ │
└─────────────────────────────────────────────────────────────────────────┘
How Aadhaar Makes It Tractable:
DEDUPLICATION OPTIMIZATION STRATEGIES
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ LAYER 1: DEMOGRAPHIC BLOCKING │
│ ───────────────────────────── │
│ │
│ Before biometric matching, partition by: │
│ • Gender (2 partitions) │
│ • Age range (10-year buckets = 10 partitions) │
│ • State (36 partitions) │
│ • Name phonetic hash (100 partitions) │
│ │
│ Effective reduction: 2 × 10 × 36 × 100 = 72,000x smaller search │
│ │
│ 1.4B / 72,000 = 19,444 candidate matches per enrollment │
│ (vs 1.4 billion without blocking) │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ LAYER 2: MULTI-MODAL FUSION │
│ ─────────────────────────── │
│ │
│ Fingerprint (10 fingers) + Iris (2 eyes) combined: │
│ │
│ Fingerprint score (0-100) × weight + │
│ Iris score (0-100) × weight = │
│ Final fusion score │
│ │
│ Using both modalities: │
│ • Handles worn fingerprints (use iris) │
│ • Handles cataracts (use fingerprint) │
│ • Much higher accuracy than either alone │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ LAYER 3: THREE-WAY ABIS CONSENSUS │
│ ───────────────────────────────── │
│ │
│ Three independent vendors run deduplication: │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ ABIS 1 │ │ ABIS 2 │ │ ABIS 3 │ │
│ │(Vendor A) │ │(Vendor B) │ │(Vendor C) │ │
│ └────┬──────┘ └────┬──────┘ └────┬──────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌───────────┐ │
│ │ Consensus │ │
│ │ Engine │ │
│ └───────────┘ │
│ │
│ Decision rules: │
│ • 3/3 UNIQUE → Accept enrollment │
│ • 3/3 DUPLICATE → Reject enrollment │
│ • 2/3 agree → Follow majority │
│ • Mixed/uncertain → Manual adjudication │
│ │
│ Why three vendors? │
│ • Different algorithms catch different edge cases │
│ • No single vendor lock-in │
│ • Higher accuracy through consensus │
│ • Continuous quality competition │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# deduplication/abis_orchestrator.py
"""
ABIS (Automated Biometric Identification System) Orchestration
Aadhaar uses three independent ABIS vendors for deduplication.
This provides redundancy, accuracy, and vendor neutrality.
"""
from dataclasses import dataclass
from typing import List, Optional, Tuple
from enum import Enum
import asyncio
class DeduplicationResult(Enum):
UNIQUE = "unique" # No duplicates found
DUPLICATE = "duplicate" # Duplicate found
MANUAL_REVIEW = "review" # Uncertain, needs human review
@dataclass
class ABISMatch:
candidate_aadhaar: str
fingerprint_score: float # 0-100
iris_score: float # 0-100
fusion_score: float # Combined score
confidence: str # HIGH, MEDIUM, LOW
@dataclass
class ABISResponse:
vendor_id: str
result: DeduplicationResult
matches: List[ABISMatch]
processing_time_ms: int
class ABISOrchestrator:
"""
Orchestrates deduplication across three ABIS vendors.
Aadhaar's multi-ABIS approach:
1. Send enrollment to all three vendors in parallel
2. Each vendor searches against their copy of the database
3. Consensus determines final result
"""
def __init__(
self,
abis_clients: List, # Three ABIS vendor clients
demographic_filter,
manual_review_queue
):
self.abis_clients = abis_clients
self.demo_filter = demographic_filter
self.review_queue = manual_review_queue
# Thresholds for decision
self.duplicate_threshold = 80 # Fusion score > 80 = duplicate
self.unique_threshold = 30 # Fusion score < 30 = unique
async def deduplicate(
self,
enrollment_packet: dict
) -> Tuple[DeduplicationResult, Optional[str]]:
"""
Main deduplication flow.
Returns:
(result, duplicate_aadhaar if found)
"""
# Step 1: Demographic blocking to reduce search space
candidate_pool = await self.demo_filter.get_candidates(
gender=enrollment_packet['gender'],
dob=enrollment_packet['dob'],
state=enrollment_packet['state'],
name_phonetic=enrollment_packet['name_phonetic']
)
# Log the reduction achieved
reduction_ratio = 1_400_000_000 / len(candidate_pool)
print(f"Demographic blocking: {len(candidate_pool):,} candidates")
print(f"Search space reduced by {reduction_ratio:,.0f}x")
# Step 2: Send to all three ABIS in parallel
abis_tasks = [
client.search(
fingerprints=enrollment_packet['fingerprints'],
irises=enrollment_packet['irises'],
candidate_pool=candidate_pool
)
for client in self.abis_clients
]
responses: List[ABISResponse] = await asyncio.gather(*abis_tasks)
# Step 3: Consensus decision
return self._consensus_decision(responses)
def _consensus_decision(
self,
responses: List[ABISResponse]
) -> Tuple[DeduplicationResult, Optional[str]]:
"""
Three-way consensus logic.
Aadhaar requires 2/3 agreement for automated decision.
Mixed results go to manual adjudication.
"""
unique_count = sum(
1 for r in responses if r.result == DeduplicationResult.UNIQUE
)
duplicate_count = sum(
1 for r in responses if r.result == DeduplicationResult.DUPLICATE
)
# Case 1: All three agree UNIQUE
if unique_count == 3:
return (DeduplicationResult.UNIQUE, None)
# Case 2: All three agree DUPLICATE
if duplicate_count == 3:
# Find the matching Aadhaar (should be same across all)
duplicate_aadhaar = self._find_common_match(responses)
return (DeduplicationResult.DUPLICATE, duplicate_aadhaar)
# Case 3: 2/3 agree UNIQUE
if unique_count >= 2:
return (DeduplicationResult.UNIQUE, None)
# Case 4: 2/3 agree DUPLICATE
if duplicate_count >= 2:
duplicate_aadhaar = self._find_common_match(responses)
return (DeduplicationResult.DUPLICATE, duplicate_aadhaar)
# Case 5: No consensus — manual review
# Queue for human adjudicator
return (DeduplicationResult.MANUAL_REVIEW, None)
def _find_common_match(
self,
responses: List[ABISResponse]
) -> Optional[str]:
"""
Find the Aadhaar number that multiple ABIS agree is a duplicate.
"""
# Collect all top matches
match_counts = {}
for response in responses:
if response.matches:
top_match = response.matches[0]
aadhaar = top_match.candidate_aadhaar
match_counts[aadhaar] = match_counts.get(aadhaar, 0) + 1
# Return the one with most agreement
if match_counts:
return max(match_counts, key=match_counts.get)
return None
class DemographicBlockingFilter:
"""
Pre-filters the biometric search space using demographics.
This is crucial for making billion-scale deduplication tractable.
"""
def __init__(self, database):
self.db = database
async def get_candidates(
self,
gender: str,
dob: str,
state: str,
name_phonetic: str
) -> List[str]:
"""
Get candidate Aadhaar numbers that match demographic criteria.
Reduces 1.4 billion to ~20,000-50,000 candidates.
"""
# Parse DOB to get age range
birth_year = int(dob[:4])
age_range_start = birth_year - 5
age_range_end = birth_year + 5
# Query with demographic filters
candidates = await self.db.query("""
SELECT aadhaar_number
FROM residents
WHERE gender = ?
AND birth_year BETWEEN ? AND ?
AND state_code = ?
AND name_phonetic_hash = ?
""", [gender, age_range_start, age_range_end,
state, self._phonetic_hash(name_phonetic)])
return [row['aadhaar_number'] for row in candidates]
def _phonetic_hash(self, name: str) -> str:
"""
Generate phonetic hash for name matching.
Handles spelling variations:
"Rahul" and "Rahool" → same hash
"Priya" and "Priyaa" → same hash
"""
# Simplified phonetic algorithm (actual uses Soundex variant)
# Remove vowels, normalize consonants
consonants = ''.join(c for c in name.upper() if c not in 'AEIOU')
return consonants[:4].ljust(4, '0')
Deep Dive 2: Authentication in 200 Milliseconds
Week 2 concepts: Timeouts, latency budgets. Week 4 concepts: Caching.
You: "Authentication must verify identity in under 200ms. This is 1:1 matching — much simpler than deduplication, but still demanding at scale."
AUTHENTICATION LATENCY BUDGET
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ Total Budget: 200ms │
│ │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ BREAKDOWN │ │
│ │ │ │
│ │ Network (AUA → ASA → CIDR → ASA → AUA): 50ms │ │
│ │ ├── AUA to ASA: 15ms │ │
│ │ ├── ASA to CIDR: 10ms │ │
│ │ ├── CIDR to ASA: 10ms │ │
│ │ └── ASA to AUA: 15ms │ │
│ │ │ │
│ │ Cryptographic operations: 30ms │ │
│ │ ├── Decrypt PID block (at CIDR): 10ms │ │
│ │ ├── Signature verification: 5ms │ │
│ │ └── Sign response: 15ms │ │
│ │ │ │
│ │ Database lookup: 20ms │ │
│ │ ├── Find Aadhaar record: 10ms │ │
│ │ └── Load biometric template: 10ms │ │
│ │ │ │
│ │ Biometric 1:1 matching: 80ms │ │
│ │ ├── Fingerprint match: 40ms │ │
│ │ └── Iris match (if used): 40ms │ │
│ │ │ │
│ │ Processing overhead: 20ms │ │
│ │ │ │
│ │ Total: 200ms │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# authentication/auth_service.py
"""
Aadhaar Authentication Service
Processes 90+ million authentications per day with <200ms latency.
Returns only Yes/No — never exposes biometric or demographic data.
"""
from dataclasses import dataclass
from typing import Optional
from enum import Enum
from datetime import datetime
import asyncio
class AuthMode(Enum):
DEMOGRAPHIC = "demo" # Name/address matching
OTP = "otp" # One-time password
FINGERPRINT = "fmr" # Fingerprint biometric
IRIS = "iir" # Iris biometric
FACE = "fid" # Face biometric
MULTI_FACTOR = "mf" # Combination
@dataclass
class AuthRequest:
aadhaar_number: str # Or VID (Virtual ID)
auth_mode: AuthMode
pid_block: bytes # Encrypted biometric/OTP
aua_code: str # Authentication User Agency
timestamp: datetime
transaction_id: str
consent: bool # Must be True
@dataclass
class AuthResponse:
transaction_id: str
status: str # "y" (yes) or "n" (no)
error_code: Optional[str] # If status is "n"
auth_token: Optional[str] # Unique token for this auth
timestamp: datetime
# NOTE: No PII is ever returned!
class AadhaarAuthService:
"""
Core authentication service running in CIDR.
Security principles:
1. All requests encrypted with 2048-bit PKI
2. Biometric data decrypted only inside CIDR
3. Response is only Yes/No (no data leakage)
4. All transactions logged for audit
"""
def __init__(
self,
biometric_db,
biometric_matcher,
otp_service,
hsm_client, # Hardware Security Module
audit_logger
):
self.db = biometric_db
self.matcher = biometric_matcher
self.otp = otp_service
self.hsm = hsm_client
self.audit = audit_logger
# Performance tuning
self.template_cache = {} # LRU cache for hot Aadhaars
self.cache_ttl = 300 # 5 minutes
async def authenticate(
self,
request: AuthRequest
) -> AuthResponse:
"""
Main authentication flow.
Must complete in <200ms.
"""
start_time = datetime.utcnow()
try:
# Step 1: Validate request format
self._validate_request(request)
# Step 2: Decrypt PID block using HSM
# Only CIDR's HSM can decrypt
pid_data = await self.hsm.decrypt_pid(request.pid_block)
# Step 3: Resolve Aadhaar number (handle VID)
aadhaar = await self._resolve_aadhaar(request.aadhaar_number)
# Step 4: Load resident's template (with caching)
resident_template = await self._load_template(aadhaar)
# Step 5: Perform matching based on auth mode
match_result = await self._perform_match(
mode=request.auth_mode,
pid_data=pid_data,
stored_template=resident_template
)
# Step 6: Generate response
response = AuthResponse(
transaction_id=request.transaction_id,
status="y" if match_result.success else "n",
error_code=match_result.error_code,
auth_token=self._generate_token(aadhaar, request.aua_code),
timestamp=datetime.utcnow()
)
# Step 7: Audit logging (async, don't wait)
asyncio.create_task(self.audit.log(
aadhaar=aadhaar,
aua_code=request.aua_code,
auth_mode=request.auth_mode,
result=response.status,
latency_ms=(datetime.utcnow() - start_time).total_seconds() * 1000
))
return response
except ValidationError as e:
return self._error_response(request, str(e))
except Exception as e:
# Never expose internal errors
return self._error_response(request, "INTERNAL_ERROR")
async def _load_template(self, aadhaar: str) -> dict:
"""
Load biometric template with caching.
Hot Aadhaars (frequently authenticated) are cached.
"""
# Check cache first
if aadhaar in self.template_cache:
cached = self.template_cache[aadhaar]
if cached['expires'] > datetime.utcnow():
return cached['template']
# Cache miss — load from database
template = await self.db.get_template(aadhaar)
# Cache for hot Aadhaars
self.template_cache[aadhaar] = {
'template': template,
'expires': datetime.utcnow() + timedelta(seconds=self.cache_ttl)
}
return template
async def _perform_match(
self,
mode: AuthMode,
pid_data: dict,
stored_template: dict
) -> MatchResult:
"""
Perform biometric/demographic/OTP matching.
"""
if mode == AuthMode.FINGERPRINT:
# 1:1 fingerprint matching
return await self.matcher.match_fingerprint(
captured=pid_data['fingerprint'],
stored=stored_template['fingerprints'],
finger_position=pid_data.get('position', 'ANY')
)
elif mode == AuthMode.IRIS:
# 1:1 iris matching
return await self.matcher.match_iris(
captured=pid_data['iris'],
stored=stored_template['irises']
)
elif mode == AuthMode.FACE:
# AI-powered face matching
return await self.matcher.match_face(
captured=pid_data['face_image'],
stored=stored_template['photo'],
liveness_check=pid_data.get('liveness_data')
)
elif mode == AuthMode.OTP:
# Verify OTP sent to registered mobile
return await self.otp.verify(
aadhaar=stored_template['aadhaar'],
submitted_otp=pid_data['otp']
)
elif mode == AuthMode.DEMOGRAPHIC:
# Fuzzy matching on name/address
return self._demographic_match(
submitted=pid_data['demographics'],
stored=stored_template['demographics']
)
def _demographic_match(self, submitted: dict, stored: dict) -> MatchResult:
"""
Fuzzy matching for name and address.
Handles variations like:
- "Raj Kumar" vs "Rajkumar"
- "Bangalore" vs "Bengaluru"
- Hindi transliterations
"""
name_score = self._fuzzy_name_match(
submitted.get('name', ''),
stored['name']
)
address_score = self._fuzzy_address_match(
submitted.get('address', ''),
stored['address']
)
# Thresholds from UIDAI guidelines
if name_score >= submitted.get('match_threshold', 100):
return MatchResult(success=True)
return MatchResult(success=False, error_code="DEMO_MISMATCH")
Deep Dive 3: Security Architecture — Protecting Billion Biometrics
Week 9 concepts: Security, encryption, zero-trust.
You: "Aadhaar stores the biometrics of 1.4 billion people. This is the ultimate honeypot. Security is existential."
AADHAAR SECURITY LAYERS
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ LAYER 1: ENCRYPTION EVERYWHERE │
│ ────────────────────────────── │
│ │
│ At Capture: │
│ • Biometrics encrypted on enrollment device │
│ • 2048-bit PKI encryption │
│ • Only CIDR has private key to decrypt │
│ │
│ In Transit: │
│ • All communication over encrypted channels │
│ • TLS 1.2+ mandatory │
│ • Dedicated leased lines (not public internet) │
│ │
│ At Rest: │
│ • AES-256 encryption for stored data │
│ • Even within CIDR, data is encrypted │
│ • Keys stored in HSM (Hardware Security Module) │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ LAYER 2: TAMPER DETECTION │
│ ───────────────────────── │
│ │
│ Every enrollment packet includes: │
│ • HMAC for integrity verification │
│ • Operator's biometric signature │
│ • Supervisor's biometric signature (for exceptions) │
│ • GPS coordinates of enrollment station │
│ • Timestamp │
│ • Device ID │
│ │
│ Any tampering is detectable and traceable │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ LAYER 3: ACCESS CONTROL │
│ ─────────────────────── │
│ │
│ CIDR access: │
│ • Only UIDAI employees (very few) │
│ • Multi-factor authentication required │
│ • All access logged and audited │
│ • No external access to raw biometrics │
│ │
│ Partner access (AUA/ASA): │
│ • Can only call authentication API │
│ • Cannot query or download data │
│ • Rate limited per entity │
│ • Licensed and audited │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ LAYER 4: RESPONSE MINIMIZATION │
│ ────────────────────────────── │
│ │
│ Authentication returns ONLY: │
│ • Yes (match) or No (no match) │
│ • Transaction ID │
│ • Timestamp │
│ │
│ NEVER returns: │
│ • Biometric data │
│ • Demographic data (unless e-KYC with consent) │
│ • Match scores │
│ • Reason for failure (in detail) │
│ │
│ This prevents information leakage │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Privacy Features Added Over Time:
PRIVACY ENHANCEMENTS
1. VIRTUAL ID (VID) — Introduced 2018
─────────────────────────────────
Problem: Every authentication exposes Aadhaar number
Solution: 16-digit temporary ID that maps to Aadhaar
Resident generates VID → Uses VID instead of Aadhaar
Each VID is:
• Revocable (generate new anytime)
• Mappable only by CIDR
• Usable for authentication
AUA never sees actual Aadhaar number
2. TOKENIZATION — For recurring services
─────────────────────────────────────
Problem: Same Aadhaar used at multiple services
Services could collude to track user
Solution: Each AUA gets a unique token for each Aadhaar
Aadhaar 1234-5678-9012 →
Bank A: Token ABC123
Telecom B: Token XYZ789
Insurance C: Token PQR456
Services cannot correlate tokens
3. MASKED AADHAAR
───────────────
Display: XXXX-XXXX-9012
Only last 4 digits visible
Used for documents that need to show Aadhaar reference
4. AUTHENTICATION HISTORY
───────────────────────
Resident can see:
• Who authenticated their Aadhaar
• When
• What type of authentication
Provides transparency and detects misuse
# security/encryption_service.py
"""
Aadhaar Encryption Service
All biometric data is encrypted at the point of capture.
Only CIDR can decrypt using HSM-protected private keys.
"""
from dataclasses import dataclass
from typing import Tuple
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
import hmac
import hashlib
class PIDBlockEncryption:
"""
PID (Personal Identity Data) Block encryption.
The PID block contains biometric/OTP data captured at
the authentication point. It's encrypted before transmission.
Encryption scheme:
1. Generate random session key (AES-256)
2. Encrypt biometric data with session key
3. Encrypt session key with UIDAI's public key (RSA-2048)
4. Add HMAC for integrity
"""
def __init__(self, uidai_public_key: bytes):
self.uidai_public_key = serialization.load_pem_public_key(
uidai_public_key
)
def encrypt_pid(
self,
biometric_data: bytes,
timestamp: str,
device_id: str
) -> Tuple[bytes, bytes]:
"""
Encrypt PID block for transmission to CIDR.
Returns:
(encrypted_data, encrypted_session_key)
"""
# Generate random session key
session_key = os.urandom(32) # 256 bits
iv = os.urandom(12) # 96 bits for GCM
# Create PID plaintext with metadata
pid_plaintext = self._create_pid_xml(
biometric_data=biometric_data,
timestamp=timestamp,
device_id=device_id
)
# Encrypt with AES-256-GCM
cipher = Cipher(algorithms.AES(session_key), modes.GCM(iv))
encryptor = cipher.encryptor()
ciphertext = encryptor.update(pid_plaintext) + encryptor.finalize()
# Encrypt session key with UIDAI's RSA public key
encrypted_session_key = self.uidai_public_key.encrypt(
session_key + iv, # Include IV
padding.OAEP(
mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(),
label=None
)
)
# Add HMAC for integrity
hmac_value = hmac.new(
session_key,
ciphertext,
hashlib.sha256
).digest()
return (ciphertext + encryptor.tag + hmac_value,
encrypted_session_key)
class HSMKeyManager:
"""
Hardware Security Module interface.
All cryptographic keys are stored and used within HSM.
Keys never leave the HSM in plaintext.
UIDAI uses FIPS 140-2 Level 3 certified HSMs.
"""
def __init__(self, hsm_connection):
self.hsm = hsm_connection
async def decrypt_pid(self, encrypted_pid: bytes,
encrypted_key: bytes) -> dict:
"""
Decrypt PID block inside HSM.
The private key never leaves the HSM.
Decryption happens entirely within the HSM.
"""
# Send to HSM for decryption
decrypted = await self.hsm.decrypt(
data=encrypted_pid,
encrypted_key=encrypted_key,
key_id="UIDAI_AUTH_PRIVATE_KEY",
algorithm="RSA-OAEP-256"
)
return self._parse_pid_xml(decrypted)
async def sign_response(self, response_data: bytes) -> bytes:
"""
Sign authentication response using HSM.
All responses are digitally signed so AUAs can
verify they came from authentic CIDR.
"""
signature = await self.hsm.sign(
data=response_data,
key_id="UIDAI_SIGNING_KEY",
algorithm="RSA-SHA256"
)
return signature
class AadhaarDataVault:
"""
Secure storage for Aadhaar numbers at AUA/KUA.
UIDAI mandates that any entity storing Aadhaar numbers
must use an "Aadhaar Data Vault" with:
- AES-256 encryption
- Keys in HSM
- Access logging
- No plaintext storage
"""
def __init__(self, hsm_client, database):
self.hsm = hsm_client
self.db = database
async def store_aadhaar(
self,
reference_id: str, # Your internal customer ID
aadhaar_number: str
):
"""
Store Aadhaar number securely.
"""
# Generate reference key in HSM
encrypted_aadhaar = await self.hsm.encrypt(
data=aadhaar_number.encode(),
key_id="AADHAAR_VAULT_KEY"
)
# Store only encrypted value
await self.db.insert({
'reference_id': reference_id,
'encrypted_aadhaar': encrypted_aadhaar,
'created_at': datetime.utcnow()
})
async def get_aadhaar(self, reference_id: str) -> str:
"""
Retrieve and decrypt Aadhaar number.
"""
record = await self.db.get(reference_id)
# Decrypt in HSM
aadhaar = await self.hsm.decrypt(
data=record['encrypted_aadhaar'],
key_id="AADHAAR_VAULT_KEY"
)
# Log access
await self._log_access(reference_id)
return aadhaar.decode()
Deep Dive 4: Face Authentication — AI at Scale
Week 10 concepts: Operational excellence, innovation.
You: "Face authentication was introduced in 2021 and has exploded to 18 million transactions per month. It's AI-powered and developed in-house by UIDAI."
FACE AUTHENTICATION EVOLUTION
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ WHY FACE AUTHENTICATION? │
│ ───────────────────────── │
│ │
│ Problems with fingerprint: │
│ • Manual laborers: Worn fingerprints │
│ • Elderly: Faded fingerprints │
│ • Amputees: Missing fingers │
│ • Skin conditions: Temporary issues │
│ • COVID-19: Hygiene concerns with touch-based │
│ │
│ Face authentication advantages: │
│ • Contactless (post-COVID preference) │
│ • Works on any smartphone │
│ • More inclusive (no physical requirements) │
│ • Convenient for remote authentication │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ GROWTH TRAJECTORY │
│ ───────────────── │
│ │
│ Oct 2021: Launch │
│ Dec 2023: 100 crore (1 billion) cumulative │
│ Jan 2025: 12 crore (120 million) per month │
│ Sep 2025: 1.5 crore (15 million) per DAY (record) │
│ │
│ Adoption: 150+ government and private entities │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# authentication/face_auth.py
"""
UIDAI Face Authentication Service
AI/ML-powered face matching developed in-house by UIDAI.
Uses liveness detection to prevent spoofing.
"""
from dataclasses import dataclass
from typing import Tuple
import numpy as np
@dataclass
class FaceAuthRequest:
aadhaar_or_vid: str
face_image: bytes # Captured selfie
liveness_data: dict # Blink detection, head movement
device_info: dict # Camera specs, OS version
@dataclass
class FaceAuthResult:
match: bool
confidence: float # 0-100
liveness_verified: bool
error_code: str = None
class FaceAuthenticationService:
"""
Face authentication with liveness detection.
Architecture:
1. Liveness detection (prevent photo/video attacks)
2. Face detection and alignment
3. Feature extraction (deep learning)
4. 1:1 matching against stored photo
"""
def __init__(
self,
face_detector,
liveness_model,
face_encoder,
match_threshold: float = 0.85
):
self.detector = face_detector
self.liveness = liveness_model
self.encoder = face_encoder
self.threshold = match_threshold
async def authenticate(
self,
request: FaceAuthRequest,
stored_photo: bytes
) -> FaceAuthResult:
"""
Perform face authentication.
Steps:
1. Verify liveness (not a photo/video)
2. Detect and align faces
3. Extract embeddings
4. Compare embeddings
"""
# Step 1: Liveness verification
liveness_result = await self._verify_liveness(
image=request.face_image,
liveness_data=request.liveness_data
)
if not liveness_result.is_live:
return FaceAuthResult(
match=False,
confidence=0,
liveness_verified=False,
error_code="LIVENESS_FAILED"
)
# Step 2: Face detection and quality check
captured_face = await self._detect_and_align(request.face_image)
stored_face = await self._detect_and_align(stored_photo)
if captured_face is None:
return FaceAuthResult(
match=False,
confidence=0,
liveness_verified=True,
error_code="FACE_NOT_DETECTED"
)
# Step 3: Extract face embeddings
captured_embedding = await self.encoder.encode(captured_face)
stored_embedding = await self.encoder.encode(stored_face)
# Step 4: Compare embeddings
similarity = self._cosine_similarity(
captured_embedding,
stored_embedding
)
# Convert to percentage
confidence = (similarity + 1) / 2 * 100
return FaceAuthResult(
match=confidence >= self.threshold * 100,
confidence=confidence,
liveness_verified=True
)
async def _verify_liveness(
self,
image: bytes,
liveness_data: dict
) -> LivenessResult:
"""
Verify the face is from a live person.
Liveness checks:
1. Texture analysis (detect printed photos)
2. Depth estimation (detect flat screens)
3. Eye blink detection (detect videos)
4. Random challenge-response (head movement)
"""
# Challenge: User was asked to blink/move head
challenge_type = liveness_data.get('challenge_type')
frames = liveness_data.get('frames', [])
if challenge_type == 'BLINK':
# Detect eye blink across frames
return await self.liveness.detect_blink(frames)
elif challenge_type == 'HEAD_TURN':
# Detect head movement
return await self.liveness.detect_head_movement(frames)
elif challenge_type == 'PASSIVE':
# Passive liveness (texture + depth analysis)
return await self.liveness.passive_check(image)
return LivenessResult(is_live=False)
def _cosine_similarity(
self,
embedding1: np.ndarray,
embedding2: np.ndarray
) -> float:
"""
Cosine similarity between face embeddings.
Range: -1 to 1 (higher = more similar)
"""
dot_product = np.dot(embedding1, embedding2)
norm1 = np.linalg.norm(embedding1)
norm2 = np.linalg.norm(embedding2)
return dot_product / (norm1 * norm2)
class LivenessDetector:
"""
Deep learning model for liveness detection.
Trained to distinguish:
- Real faces
- Printed photos
- Screen displays (replay attacks)
- 3D masks
"""
def __init__(self, model_path: str):
self.model = self._load_model(model_path)
async def passive_check(self, image: bytes) -> LivenessResult:
"""
Passive liveness without user action.
Analyzes:
- Moiré patterns (screen artifacts)
- Color distribution
- Texture frequency
- Specular reflection
"""
features = self._extract_liveness_features(image)
# Model predicts: real (1) vs spoof (0)
prediction = self.model.predict(features)
return LivenessResult(
is_live=prediction > 0.7,
confidence=prediction,
method="PASSIVE"
)
async def detect_blink(self, frames: list) -> LivenessResult:
"""
Detect eye blink across video frames.
A real person blinks; a photo doesn't.
"""
eye_aspect_ratios = []
for frame in frames:
# Detect eyes
eyes = self._detect_eyes(frame)
if eyes:
ear = self._eye_aspect_ratio(eyes)
eye_aspect_ratios.append(ear)
# Blink = dip in eye aspect ratio
if len(eye_aspect_ratios) > 5:
min_ear = min(eye_aspect_ratios)
max_ear = max(eye_aspect_ratios)
# Significant dip indicates blink
if (max_ear - min_ear) > 0.15:
return LivenessResult(is_live=True, method="BLINK")
return LivenessResult(is_live=False, method="BLINK")
Phase 5: Scaling and Edge Cases
Interviewer: "Aadhaar went from 0 to 1 billion enrollments in about 6 years. How did they scale the enrollment infrastructure?"
Enrollment at Village Scale
ENROLLMENT INFRASTRUCTURE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ THE CHALLENGE │
│ ───────────── │
│ │
│ • 640,000+ villages in India │
│ • Many with no electricity, no internet │
│ • Extreme temperatures (deserts, mountains) │
│ • Low literacy levels │
│ • Need to enroll 1+ million people per day │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ THE SOLUTION: MOBILE ENROLLMENT CAMPS │
│ ───────────────────────────────────── │
│ │
│ Equipment transported (sometimes by donkeys!): │
│ • Ruggedized laptops │
│ • USB fingerprint scanners │
│ • Iris cameras │
│ • Web cameras (for photos) │
│ • Portable generators │
│ • Tables, chairs, canopies │
│ │
│ Personnel: │
│ • 150,000+ certified operators │
│ • Supervisors for exception handling │
│ • ~50 enrollments per station per day │
│ │
│ Peak capacity: │
│ • 60,000-80,000 enrollment stations │
│ • 1+ million new enrollments per day │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Edge Cases
EDGE CASE 1: Biometric Exceptions
Problem: Not everyone can provide all biometrics
- Missing fingers (accidents, leprosy)
- Cataract patients (can't capture iris)
- Worn fingerprints (manual laborers)
- Children (biometrics change as they grow)
Solution:
├── Multi-modal: If fingerprint fails, use iris
├── Best-finger approach: Use whichever fingers work
├── Exception handling: Supervisor approval for special cases
├── Child enrollment: Mandatory biometric update at 5 and 15 years
└── Best Available Data (BAD) mode for extreme cases
EDGE CASE 2: Offline Enrollment
Problem: No internet in remote villages
Solution:
├── Enrollment client works entirely offline
├── Packets stored locally (encrypted)
├── Sync when connectivity available
├── USB-based upload via registrar
└── 30-day buffer for packet upload
EDGE CASE 3: Duplicate Enrollment Attempts
Problem: People trying to get multiple Aadhaars for fraud
Solution:
├── Three-way ABIS consensus
├── Manual adjudication for borderline cases
├── Reject if duplicate found
├── Audit trail for investigation
└── Criminal penalties for fraud
EDGE CASE 4: Authentication Failures
Problem: Genuine person fails authentication
Causes:
├── Worn fingerprints (temporary or permanent)
├── Cuts/injuries on fingers
├── Wet/dirty fingers
├── Sensor quality issues
├── Aging (biometrics change over time)
Solution:
├── Try multiple fingers
├── Fall back to iris
├── Fall back to OTP
├── Face authentication option
├── Biometric update facility
└── Exception handling mode for genuine failures
EDGE CASE 5: System Under Attack
Problem: DDoS or brute-force attacks
Mitigation:
├── Rate limiting per AUA
├── IP whitelisting for ASAs
├── No direct internet exposure
├── Anomaly detection
└── Fallback to degraded mode
Phase 6: Monitoring and Operations
You: "With 90 million daily authentications, operational excellence is critical."
MONITORING DASHBOARD
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ REAL-TIME METRICS │
│ │
│ Authentication Rate │
│ ├── Current TPS: 1,042 auth/sec │
│ ├── Today's Total: 67.2M authentications │
│ ├── Success Rate: 99.2% │
│ └── p99 Latency: 185ms │
│ │
│ By Authentication Type │
│ ├── Fingerprint: 58% [████████████ ] │
│ ├── OTP: 22% [████ ] │
│ ├── Face: 12% [██ ] │
│ ├── Iris: 5% [█ ] │
│ └── Demographic: 3% [ ] │
│ │
│ Top AUAs (by volume) │
│ ├── SBI Bank: 12.3M [████████ ] │
│ ├── NPCI/UPI: 9.8M [██████ ] │
│ ├── Jio Telecom: 7.2M [█████ ] │
│ ├── HDFC Bank: 5.6M [████ ] │
│ └── Others: 32.3M │
│ │
│ Infrastructure Health │
│ ├── CIDR Bengaluru: ✓ Healthy (CPU: 45%) │
│ ├── CIDR Manesar: ✓ Healthy (CPU: 42%) │
│ ├── ABIS 1: ✓ Healthy (Queue: 234) │
│ ├── ABIS 2: ✓ Healthy (Queue: 189) │
│ └── ABIS 3: ✓ Healthy (Queue: 267) │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Interview Conclusion
Interviewer: "Excellent walkthrough. A few quick questions:"
Interviewer: "What's the hardest part of building a system like Aadhaar?"
You: "Three things:
-
Biometric deduplication at scale — Proving uniqueness against 1.4 billion records requires clever algorithms, demographic blocking, and multi-ABIS consensus. Brute force is mathematically impossible.
-
Inclusive design — The system must work for manual laborers with worn fingerprints, elderly with cataracts, amputees, and people in villages with no electricity. You can't just optimize for the happy path.
-
Security of the crown jewels — If the CIDR is breached, the biometrics of 1.4 billion people are exposed. There's no 'password reset' for fingerprints. The security architecture must be bulletproof."
Interviewer: "What lessons from Aadhaar apply to other large-scale systems?"
You: "Several key lessons:
-
API-first thinking — Aadhaar was designed as a platform from day one. The authentication API has enabled hundreds of services. UPI, DigiLocker, ABDM — all built on Aadhaar's identity layer.
-
Vendor neutrality — Three ABIS vendors, open APIs, no lock-in. This enabled continuous improvement and prevented any single vendor from becoming critical.
-
Offline-first design — For systems that must work in challenging environments, assume no connectivity and design for sync.
-
Minimal data principle — Aadhaar authentication returns only Yes/No. This minimizes privacy exposure and attack surface.
-
Invest in inclusion — Adding face authentication made the system accessible to millions who struggled with fingerprints. Inclusion isn't just ethics — it's good engineering."
Summary: Concepts Applied from 10-Week Course
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ CONCEPTS FROM 10-WEEK COURSE IN AADHAAR DESIGN │
│ │
│ WEEK 1: DATA AT SCALE │
│ ├── Partitioning: Demographic blocking reduces search space │
│ ├── Sharding: CIDR distributed across data centers │
│ └── Replication: Active-active for disaster recovery │
│ │
│ WEEK 2: FAILURE-FIRST DESIGN │
│ ├── Offline-first: Enrollment works without connectivity │
│ ├── Graceful degradation: Fall back to OTP if biometric fails │
│ ├── Timeouts: 200ms latency budget for authentication │
│ └── Retry: Multi-finger, multi-modality attempts │
│ │
│ WEEK 3: MESSAGING & ASYNC │
│ ├── Queue-based: Enrollment packets queued for processing │
│ ├── Async deduplication: Days/weeks for complex cases │
│ └── Audit trail: All transactions logged asynchronously │
│ │
│ WEEK 4: CACHING │
│ ├── Template caching: Hot Aadhaars cached for fast auth │
│ ├── Session caching: Reduce database lookups │
│ └── Pre-computed: Demographic indices for blocking │
│ │
│ WEEK 5: CONSISTENCY │
│ ├── Strong consistency: Deduplication must be accurate │
│ ├── Consensus: 2-of-3 ABIS agreement for decisions │
│ └── Uniqueness guarantee: Core requirement of the system │
│ │
│ WEEK 9: SECURITY │
│ ├── 2048-bit PKI encryption throughout │
│ ├── HSM for key management │
│ ├── Zero-trust architecture │
│ ├── Virtual ID for privacy │
│ └── Tokenization to prevent tracking │
│ │
│ WEEK 10: OPERATIONS │
│ ├── Multi-vendor: Three ABIS for resilience │
│ ├── SLOs: <200ms auth, 99.9% availability │
│ ├── Audit: Complete traceability of all operations │
│ └── Continuous innovation: Face auth, VID, e-KYC │
│ │
└────────────────────────────────────────────────────────────────────────┘
Why Aadhaar Matters
╔═════════════════════════════════════════════════════════════════════════╗
║ ║
║ WHY AADHAAR IS AN ENGINEERING MARVEL ║
║ ║
║ SCALE ║
║ ───── ║
║ • Largest biometric database in history (1.4 billion) ║
║ • 150+ billion authentications (and counting) ║
║ • 90+ million authentications per day ║
║ • Deduplication: Never done at billion scale before ║
║ ║
║ INCLUSION ║
║ ───────── ║
║ • Works in 640,000 villages ║
║ • Handles worn fingerprints, cataracts, amputees ║
║ • Multiple modalities (finger, iris, face, OTP) ║
║ • Low-cost enrollment (donkeys carrying equipment!) ║
║ ║
║ IMPACT ║
║ ────── ║
║ • ₹3.5+ lakh crore in DBT savings ║
║ • Millions of ghost beneficiaries eliminated ║
║ • Foundation for UPI, DigiLocker, ABDM, CoWIN ║
║ • "India Stack" model studied globally ║
║ ║
║ INNOVATION ║
║ ────────── ║
║ • First multi-ABIS system in the world ║
║ • Virtual ID for privacy (before it was trendy) ║
║ • AI-powered face authentication at scale ║
║ • Consent-based data sharing (e-KYC) ║
║ ║
║ ════════════════════════════════════════════════════════════════════ ║
║ ║
║ "Aadhaar proved that identity infrastructure can be built as ║
║ a public good, at billion scale, with inclusion at its core." ║
║ ║
╚═════════════════════════════════════════════════════════════════════════╝
Self-Assessment Checklist
After studying this case study, you should be able to:
Architecture:
- Design a biometric enrollment system with offline capability
- Explain deduplication challenges at billion scale
- Design authentication with sub-200ms latency
Distributed Systems:
- Apply demographic blocking to reduce search space
- Design multi-vendor consensus systems
- Handle offline-first data sync
Security:
- Implement end-to-end encryption with HSM
- Design privacy-preserving authentication (VID, tokenization)
- Apply zero-trust principles to sensitive data
Inclusion:
- Design for biometric edge cases
- Provide multiple authentication fallbacks
- Build systems for challenging infrastructure environments
Sources
Official UIDAI Documentation:
- UIDAI Official Website: https://uidai.gov.in/
- Aadhaar Authentication API Specification: https://uidai.gov.in/images/resource/Aadhaar_Authentication_API-2.5_Revision-1_of_January_2022.pdf
- Aadhaar e-KYC API Specification: https://uidai.gov.in/images/resource/aadhaar_ekyc_api_2_5.pdf
- UIDAI Operation Model: https://uidai.gov.in/en/ecosystem/authentication-ecosystem/operation-model.html
- Network and Server Security: https://uidai.gov.in/en/16-english-uk/aapka-aadhaar/31-network-and-server-security.html
- Enrollment Data Security: https://uidai.gov.in/en/16-english-uk/aapka-aadhaar/33-enrolment-data-security.html
- About Aadhaar Paperless Offline e-KYC: https://uidai.gov.in/en/ecosystem/authentication-devices-documents/about-aadhaar-paperless-offline-e-kyc.html
Statistics and Press Releases:
- UIDAI January 2025 Statistics: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2100685
- Aadhaar Authentication Surpasses 150 Billion: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2129121
- UIDAI August 2025 Statistics: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2163733
- IBEF Aadhaar Coverage: https://ibef.org/news/aadhaar-authentication-crosses-150-billion-transactions-powering-india-s-digital-economy-and-welfare-services
- MobileIDWorld Coverage: https://mobileidworld.com/indias-aadhaar-digital-id-system-surpasses-150-billion-authentication-transactions/
- OpenGov Asia Analysis: https://opengovasia.com/2025/02/10/aadhaars-expanding-role-in-indias-digital-economy/
Architecture and Technical Deep Dives:
- HPE Developer Portal - Aadhaar Experience: https://developer.hpe.com/blog/architecting-the-worlds-largest-biometric-identity-system-the-aadhaar-ex/
- MapR - Aadhaar Architecture: https://mapr.com/blog/architecting-worlds-largest-biometric-identity-system-aadhaar-experience/
- Teknonauts - Aadhaar Architecture: https://teknonauts.com/aadhaar-card-architecture/
- Medium - Aadhaar System Design: https://medium.com/career-drill/aadhar-system-design-39b1425a0983
- IACR ePrint - Aadhaar Security Analysis: https://eprint.iacr.org/2022/481.pdf
Biometric Technology:
- Neurotechnology and TCS ABIS: https://www.biometricupdate.com/202103/neurotechnology-to-provide-biometric-de-duplication-software-for-indias-aadhaar-program
- Neurotechnology Press Release: https://www.neurotechnology.com/press_release_india_uidai_aadhaar_id.html
- MegaMatcher ABIS: https://www.neurotechnology.com/megamatcher-abis.html
- UIDAI Role of Biometric Technology: https://www.dematerialisedid.com/PDFs/role_of_biometric_technology_in_aadhaar_jan21_2012.pdf
Security and Privacy:
- Privacy International Analysis: https://privacyinternational.org/case-study/4698/id-systems-analysed-aadhaar
- Protean Tech Security Overview: https://www.proteantech.in/articles/aadhaar-authentication-data-security-27-06-2025/
- AWS Aadhaar Data Vault: https://aws.amazon.com/blogs/publicsector/build-aadhaar-data-vault-aws/
Academic and Research:
- Taylor & Francis - Aadhaar Governing with Biometrics: https://www.tandfonline.com/doi/full/10.1080/00856401.2019.1595343
- ScienceDirect - Decoding Indian Data Governance: https://www.sciencedirect.com/science/article/pii/S2590291125001354
Further Reading
Official Documentation:
- UIDAI Developer Portal: https://uidai.gov.in/en/ecosystem/authentication-devices-documents.html
- Authentication Regulations: https://uidai.gov.in/legal-framework/aadhaar-regulations.html
- Aadhaar Act 2016: Full text with amendments
Engineering Talks:
- Dr. Pramod Varma - "Architecting World's Largest Biometric Identity System" (Strata+Hadoop World 2014)
- Nandan Nilekani - Various talks on India Stack and Aadhaar design philosophy
Engineering Blogs:
- ByteByteGo: System design breakdowns
- High Scalability: Case studies on large-scale systems
- Biometric Update: Aadhaar and biometric technology coverage
Books:
- "Designing Data-Intensive Applications" by Martin Kleppmann — Distributed systems fundamentals
- "Aadhaar: A Biometric History of India's 12-Digit Revolution" by N.S. Ramnath and Charles Assisi
Related Systems to Study:
- Estonia e-Residency: European digital identity model
- Singapore SingPass: National digital identity
- UK Verify: Federated identity approach (contrast to centralized)
- MOSIP: Open-source identity platform (inspired by Aadhaar)
Research Papers:
- "India's Aadhaar: Structure, Security, and Vulnerabilities" — IACR ePrint 2022/481
- IEEE/ACM papers on biometric deduplication at scale
End of Bonus Problem 3: Aadhaar (UIDAI)
"1.4 billion unique identities. 150 billion authentications. The foundation of India's digital public infrastructure."