System Design: National Digital ID Like India's Aadhaar: 1:N Deduplication Over 1.5 Billion People, 1:1 Authentication and Privacy
Goal: Design a national digital ID system like India's Aadhaar. Our version is Walnut ID. It gives each resident one random 12-digit number, tied to a face photo, 10 fingerprints and 2 irises.
Later, when a ration shop or a bank asks "is this really Ramesh?", it answers yes or no.
We plan for 1.5 billion people, 1 million enrollment searches a day (each one checked against everyone), 30 crore (300 million) authentications a day and a peak of 12,000 authentications a second.
Walnut ID is our design. Aadhaar is run by UIDAI (the Unique Identification Authority of India).
1. What We Are Building
🔒 Premium section
2. Requirements and Scale
2.1 What the System Must Do
| ID | Requirement |
|---|---|
| FR1 | Enroll a resident at a center, even with no network. Capture details, a face photo, 10 fingerprints and 2 irises (section 6). |
| FR2 | Compare every new enrollment with everyone already enrolled, a one-to-many search, before giving a number (section 7). |
| FR3 | Send every possible duplicate to trained reviewers (section 8). |
| FR4 | Give each new person a unique 12-digit number that is never reused, not even after death (section 4.8). |
| FR5 | Let people update their details and biometrics. Children are captured again at 5 and at 15 (section 6). |
| FR6 | Answer "is this person who they say they are?" with yes or no, by details, OTP, fingerprint, iris, face or a mix (section 9). |
| FR7 | With the person's consent, send their verified name, address and photo to an allowed agency (eKYC, section 10). |
| FR8 | Give people a signed QR code and a signed file that anyone can check without calling us (section 10). |
| FR9 | Let people make a Virtual ID (a stand-in number they can cancel), lock their biometrics and see recent checks (section 11). |
| FR10 | Deactivate numbers of people who have died and cancel duplicates found later (section 4). |
2.2 How Well It Must Do It
p50 is the time half of all requests beat. p99 is the time 99 of every 100 beat, so it shows the slow tail.
Three accuracy words are needed here. FPIR is how often a search wrongly says a new person is already enrolled.
FNIR is how often a search misses someone who is enrolled. FMR is the chance that a stranger passes as you in a 1:1 check. Section 3.3 explains all three.
An FPIR error, a false alarm, costs a reviewer's time. An FNIR error, a miss, lets someone like Mohan get a second number. An FMR error lets a stranger pass as Ramesh.
| ID | Requirement | Target |
|---|---|---|
| NFR1 | People stored and searched | 1.5 billion, growing to 2 billion |
| NFR2 | Enrollment searches | 1 million a day |
| NFR3 | Authentications | 30 crore a day, 12,000 a second at peak |
| NFR4 | Biometric check, inside the central system | p50 under 200 ms, p99 under 1 second |
| NFR4b | Biometric check, whole wait at the counter | 97% within 2 seconds |
| NFR5 | Search accuracy | FPIR at most 0.1% (at most 1 in 1,000 new people wrongly flagged as already enrolled). FNIR at most 0.05% (at most 1 in 2,000 repeat enrollments missed) |
| NFR6 | Authentication uptime | 99.99% a month, with either site alone able to carry the full load |
| NFR7 | Enrollment if one data center is lost | May pause for up to 4 hours. No packet that already got a receipt is lost |
| NFR8 | Keeping authentication records | 6 months at the central system, then deleted |
| NFR9 | What may never be stored | The purpose of an authentication; caste, religion, race, income, medical history |
| NFR10 | Keys | Our private keys only inside hardware security modules |
| NFR11 | 1:1 biometric accuracy | FMR at most 1 in 1 million per check (a stranger passes as you at most once in 1 million tries) |
Where the targets come from:
- NFR1. 145.32 crore numbers exist today (UIDAI dashboard, 2026), rounded up with room to grow. Our choice.
- NFR2. UIDAI's target since 2014. Only about 60,000 new numbers a day are issued today (2.2 crore in 2024-25).
- NFR2, why 1 million. Each child's new biometrics at 5 and 15, other biometric updates and catch-up drives also need a search against everyone. Together these fill the 1 million.
- NFR3. UIDAI's chairman said in September 2026 that UIDAI is preparing for 25 to 30 crore a day (news report). We take the top.
- NFR4. UIDAI promised "sub-second" answers (UIDAI, 2014). Our p99 matches it.
- NFR4b. In Delhi ration shops, over 97% of successful checks, all methods, were answered within 2 seconds (ISB, a business school, 2018). We use the same target.
- NFR4b, the time budget. If the central system uses up to 1 second, about 1 second is left for the device, the network, the AUA (the agency that asks) and the ASA (its carrier).
- NFR5. Goals, not yet shown at this size. UIDAI reported FPIR 0.057% and FNIR 0.035% on 84 million people (UIDAI, 2012, unaudited). Our gallery, the set of stored people, is 18 times bigger, and a bigger gallery gives more false alarms (section 3.3).
- NFR5, the newest test. Bharat ABIS, a UIDAI research paper (May 2026, not yet peer reviewed), searched 220 million adults. At 0.5% false alarms it missed 0.3% of duplicates. That is 5 times more false alarms and 6 times more misses than our goals.
- NFR6. Ours. 99.99% allows about 4.3 minutes down in a 30-day month. Today's figure is lower (section 14.2).
- NFR7. Ours, the same as UIDAI's disaster targets in a 2016 talk (section 14.2).
- NFR8 and NFR9. The Supreme Court (2018), the Regulations (2021) and the Aadhaar Act, 2016, sections 2(k) and 32(3). Agencies' own logs follow other rules (section 11.2).
- NFR11. Ours. Daugman, who invented the iris code, reports that a threshold (the score cut-off for "same person", section 3.2) of 0.317 gives about 1 false match in 1 million (Daugman, 2006). So it can be met (section 9.6).
2.3 The Numbers
These are planning numbers. Section 13 does the full sizing.
| What | Number | How we got it | Section |
|---|---|---|---|
| Auth, average | 3,472 a second | 30 crore / 86,400 seconds | 13.1 |
| Auth, design peak | 12,000 a second, each site alone | 3,472 × 3.3 = about 11,500, rounded up. 3.3 is how much busier the peak was than quiet times in 2015. We apply it to the average, which is cautious | 13.1 |
| Searches, average | 11.6 a second | 1 million a day / 86,400 seconds. One search compares one new enrollment or biometric update with everyone | 13.1 |
| Searches, planned load | 35 a second | 3 × the average (our choice). Uploads bunch in the evening, and a queue builds after any stop, so the matchers must run faster than the average | 13.1 |
| Iris comparisons | 3.0 × 10^15 a day | Each search compares each new iris with the same eye of all 1.5 billion people, so 3 billion comparisons. 1 million searches × 3 billion. We count irises only, to keep the sum simple; fingerprints add more | 13.4 |
| Gallery memory | About 20 TB per copy | 1.5 billion people × 13.5 KB of templates each (Bharat ABIS). Templates are compact numbers taken from the biometric images (section 3.2). Each of the 3 vendors keeps one full copy in memory, because reading from disk for every search is too slow | 13.5 |
| False alarms to review | Up to 1,000 a day | 1 million searches × 0.1% (our FPIR goal). Section 8.6 plans staff for 5 times more, because no system has yet shown 0.1% at this size | 8.6 |
| Auth records kept | About 55 billion | 30 crore a day × about 183 days (6 months) | 13.3 |
| Raw archive | 4.5 to 7.5 PB per copy | 1.5 billion packets × 3 to 5 MB each. 1 PB (petabyte) is 1,000 TB | 13.6 |
| Copy to the second site, average | 280 to 460 Mbit/s | 1 million packets × 3 to 5 MB = 3 to 5 TB a day. × 8 turns bytes into bits; / 86,400 seconds | 13.6 |
The last row affects uploads. A packet is normally accepted only after it is saved at both sites (section 14.5), so a slow link between sites slows uploads too. Section 13.1 explains the 3.3, and why 3 times the average clears a backlog.
2.4 Out of Scope
- Citizenship, voter ID and elections. Walnut ID shows only that a person is unique and is who they claim to be.
- The services that use the ID, such as ration shops, pensions, banks and our UPI apps. We design only how they ask and what we answer.
- Printing and posting letters. We hand a signed file to a print vendor and stop there.
3. How a National ID Works: the Words We Need
🔒 Premium section
4. What We Store: the Data and the Enrollment Packet
🔒 Premium section
5. High-Level Design
🔒 Premium section
6. Deep Dive: Enrollment and Offline Centers
🔒 Premium section
7. Deep Dive: Deduplication, 1:N Over a Billion People
🔒 Premium section
8. Deep Dive: Manual Review of Possible Duplicates
🔒 Premium section
9. Deep Dive: Authentication, 1:1
🔒 Premium section
10. Deep Dive: eKYC and Offline Checks
🔒 Premium section
11. Deep Dive: Privacy by Design
🔒 Premium section
12. Security
🔒 Premium section
13. Capacity
🔒 Premium section
14. Data Centers and Availability
🔒 Premium section
15. What Happens When Each Part Goes Down
🔒 Premium section
16. Bottlenecks
🔒 Premium section
17. Exclusion: When a Real Person Fails
🔒 Premium section
18. The Privacy Debate: Both Sides
🔒 Premium section
19. Options We Did Not Pick
🔒 Premium section
20. In the Interview (45 and 60 minutes)
🔒 Premium section
21. Further Reading
🔒 Premium section
Explore the Technologies
🔒 Premium section