அளவில் 10 நிமிடங்களில் 5M votes-ஐ எப்படிக் கையாளுவீர்கள்?

Question

IT Interview Practice · Accepted Answer

ஒவ்வொரு vote-ஐயும் நேரடியாக ஒரு database row-க்கு எழுத வேண்டாம் — **writes-ஐ buffer செய்யுங்கள், counters-ஐ shard செய்யுங்கள், eventual tally-ஐ ஏற்றுக்கொள்ளுங்கள்**. 10 நிமிடங்களில் 5M votes என்பது சராசரியாக ~8,300 votes/sec, மிக அதிக spikes உடன் (ஒரு live TV தருணம் அதை 10x செய்யலாம்). ஒரு hot single-row update-ஐ பல சுயாதீன, parallel increments ஆக மாற்றுவது தான் தந்திரம்.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## ஏன் writes-ஐ buffer செய்ய வேண்டும்

**Kafka** போன்ற ஒரு queue ingestion-ஐ tallying-இலிருந்து decouple செய்கிறது. client write ஒரு மலிவான append; ஒரு spike-இன்போது consumers பின்தங்கினால், events DB-ஐ மூழ்கடிப்பதற்குப் பதிலாக log-இல் காத்திருக்கின்றன. Kafka **replay**-ஐயும் தருகிறது — ஒரு consumer crash ஆனால், votes-ஐ இழக்காமல் கடைசி committed offset-இலிருந்து மீண்டும் process செய்கிறீர்கள்.

## Sharded counters hotspot-ஐக் கொல்கின்றன

"Option A"-க்கான ஒவ்வொரு vote-ம் `UPDATE counter SET n=n+1 WHERE id='A'` செய்தால், அந்த single row ஒரு lock-contention bottleneck ஆகிறது — ஆயிரக்கணக்கான transactions ஒரே row மீது serialize ஆகின்றன. மாறாக, ஒவ்வொரு option-ஐயும் **N shard rows** ஆகப் பிரியுங்கள் (`A:0 … A:63`). ஒவ்வொரு increment-ம் ஒரு random shard-ஐ அடைகிறது, எனவே writes N rows முழுவதும் பரவி parallel-ஆக இயங்குகின்றன. காட்டப்படும் மொத்தம் `SUM(shards)`, ஒரு aggregator-ஆல் ஒவ்வொரு வினாடி இரண்டிற்கும் ஒருமுறை கணக்கிடப்படுகிறது. Redis-இல் இது வெறும் N `INCR` keys; DynamoDB-இல், N partition keys.

## One-vote dedup

"ஒரு பயனருக்கு ஒரு vote"-ஐ ஒரு idempotency key மூலம் அமல்படுத்துங்கள்: `SADD voted:{pollId} {userId}` (அல்லது ஒரு conditional put). பயனர் ஏற்கனவே இருந்தால், increment செய்வதற்கு முன் event-ஐ drop செய்யுங்கள். இதை consumer-இல் செய்யுங்கள், client-இல் அல்ல — clients பொய் சொல்லி retry செய்கின்றன.

## நேர்காணல் கண்ணோட்டம்

**single-hot-key problem**-ஐ நீங்கள் அடையாளம் கண்டு "add more DB replicas" என்பதற்குப் பதிலாக buffering + sharding-ஐ நோக்குகிறீர்களா என்பதை நேர்காணல் செய்பவர் ஆராய்கிறார் (replicas reads-ஐ அளவிடுகின்றன, இந்த write-ஐ அல்ல). நல்லது: "ஒரு queue மற்றும் ஒரு cache பயன்படுத்து." சிறந்தது: நீங்கள் **eventual-consistency trade-off**-ஐக் குறிப்பிடுகிறீர்கள் — live எண் ஒரு வினாடி உண்மையைப் பின்தொடர்கிறது — மேலும் ஒரு vote count-க்கு அது பரவாயில்லை ஆனால் poll மூடிய பிறகு நீங்கள் authoritative-ஆக மீண்டும் கணக்கிடும் இறுதி certified result-க்கு *அல்ல* என்று வாதிடுகிறீர்கள்.

**பொதுவான பொறி:** "accuracy"-க்காக ஒவ்வொரு vote-க்கும் ஒரு database transaction பயன்படுத்துவது. இந்த அளவில் அது தான் உருகும் விஷயம்.

## சமரசங்களும் தோல்வி முறைகளும்

- **Eventual tally:** shard sums பின்தங்குகின்றன; ஒரு live counter-க்கு ஏற்கத்தக்கது, மூடும்போது reconcile செய்யுங்கள்.
- **At-least-once delivery:** Kafka redeliver செய்யலாம் — dedup increments-ஐ idempotent ஆக்குகிறது, இல்லையெனில் இரட்டை-எண்ணுகிறீர்கள்.
- **Hot shard skew:** மிகக் குறைவான shards எனில் இன்னும் contend செய்கிறீர்கள்; மிக அதிகம் எனில் summing விலையுயர்கிறது. 32–128 shards பொதுவானது.
- **Fairness/fraud:** ஒவ்வொரு IP/device-க்கும் rate-limit செய்யுங்கள்; one-vote SET தான் உங்கள் integrity boundary. அதை இழப்பது ballot stuffing-ஐ அர்த்தப்படுத்துகிறது, crash அல்ல — arguably மோசமானது.

ஏன் writes-ஐ buffer செய்ய வேண்டும்

Sharded counters hotspot-ஐக் கொல்கின்றன

One-vote dedup

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வி முறைகளும்

தொடர்புடைய கேள்விகள்