Short answer (interview-ready)
Surrogate keys provide technical identity, but natural keys enforce business correctness.
Without enforcing natural keys, a relational database cannot protect the domain from invalid or duplicate business data.
That’s the essence. Now let’s break it down.
What surrogate keys actually guarantee (and what they don’t)
A surrogate key (id) guarantees only:
- Each row is technically unique
- Rows can be referenced efficiently
It does NOT guarantee:
- One user per email
- One order per business number
- One country per ISO code
Example:
users (
id BIGSERIAL PRIMARY KEY,
email TEXT
)
This table allows:
(id=1, email=a@test.com)
(id=2, email=a@test.com) ❌
From the database point of view — everything is valid.
From the business point of view — data is corrupted.
Why natural keys must still be enforced
1️⃣ Business rules live in the database
Natural keys represent real-world uniqueness:
- Passport number
- Account number
- Order number
If the DB does not enforce them:
- You rely on application code
- You risk bugs, race conditions, partial failures
UNIQUE (email)
➡️ DB becomes the final authority, not your code.
2️⃣ Concurrency safety (huge interview point)
Two concurrent requests:
Request A: check email exists → false
Request B: check email exists → false
Both insert.
Without a DB constraint:
❌ Duplicate data
With UNIQUE (email):
✔️ One fails atomically
No amount of Java synchronized fixes this across nodes.
3️⃣ Defense in depth
Production reality:
- Multiple services
- Migrations
- Manual scripts
- Hotfixes
- Data imports
Only DB constraints protect against:
- Human error
- Script mistakes
- Partial deployments
4️⃣ Surrogate keys hide data problems
Surrogate keys make duplicates invisible:
Two users with same email → different IDs → looks fine
This leads to:
- Broken reports
- Incorrect billing
- Ghost users
Enforcing natural keys prevents silent corruption.
5️⃣ Easier reasoning & debugging
With enforced natural keys:
- Errors surface early
- Failures are explicit
- Logs show constraint violations
Without them:
- Bugs surface months later
- Data cleanup becomes painful
- Trust in data is lost
Correct real-world pattern (gold standard)
users (
id BIGSERIAL PRIMARY KEY, -- surrogate key
email TEXT NOT NULL,
UNIQUE (email) -- natural key enforced
)
This gives you:
- Stable technical identity
- Guaranteed business correctness
Both are needed.
Interview traps ❌
- “IDs are enough” ❌
- “We enforce it in code” ❌
- “We don’t need UNIQUE constraints” ❌
- “Surrogate keys prevent duplicates” ❌
All of these are red flags at senior interviews.
One-sentence senior-level answer (perfect)
Surrogate keys identify rows technically, but natural keys must still be enforced to guarantee business-level uniqueness, data integrity, and concurrency safety.
Bonus follow-up (very common)
“What happens if business rules change?”
Answer:
You change or migrate the natural constraint, not the surrogate key — which remains stable.