كيف تتعامل مع خمسة ملايين صوت خلال عشر دقائق على نطاق واسع؟

Question

IT Interview Practice · Accepted Answer

لا تكتب كل صوت مباشرة إلى صفّ قاعدة بيانات — بل **خزّن الكتابات مؤقتاً، وجزّئ العدّادات، واقبل إحصاءً نهائياً (eventual tally)**. خمسة ملايين صوت في عشر دقائق تعني نحو 8,300 صوت/ثانية في المتوسّط، مع ذرى أعلى بكثير (لحظة تلفزيونية مباشرة قد تضاعفها عشر مرّات). الحيلة هي تحويل تحديث صفّ ساخن واحد إلى زيادات مستقلة متوازية كثيرة.

```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
```

## لماذا نخزّن الكتابات مؤقتاً

طابور مثل **Kafka** يفصل الاستيعاب (ingestion) عن الإحصاء. كتابة العميل هي إلحاق (append) رخيص؛ وإن تأخّر المستهلكون أثناء الذروة تنتظر الأحداث في السجل بدل إغراق قاعدة البيانات. يعطي Kafka أيضاً **replay** — إن انهار مستهلك، تُعيد المعالجة من آخر إزاحة (offset) مُثبَّتة دون فقدان أصوات.

## العدّادات المجزّأة تقتل النقطة الساخنة

إذا كان كل صوت لـ"الخيار A" يُنفّذ `UPDATE counter SET n=n+1 WHERE id='A'`، فذلك الصفّ الواحد يصبح عنق زجاجة لتنافس الأقفال — آلاف المعاملات تُسلسَل على صفّ واحد. بدلاً من ذلك، قسّم كل خيار إلى **N صفّ مجزّأ (shard rows)** (`A:0 … A:63`). كل زيادة تصيب جزءاً عشوائياً، فتتوزّع الكتابات على N صفّ وتعمل بالتوازي. الإجمالي المعروض هو `SUM(shards)`، يحسبه مُجمِّع كل ثانية أو ثانيتين. في Redis هذه مجرّد N مفتاح `INCR`؛ وفي DynamoDB هي N مفتاح تجزئة (partition key).

## إزالة تكرار الصوت الواحد

افرِض "صوت واحد لكل مستخدم" بمفتاح idempotency: `SADD voted:{pollId} {userId}` (أو conditional put). إذا كان المستخدم موجوداً مسبقاً، أسقِط الحدث قبل الزيادة. افعل ذلك في المستهلك لا في العميل — فالعملاء يكذبون ويعيدون المحاولة.

## منظور المقابلة

يتحرّى المُحاور مدى إدراكك لـ**مشكلة المفتاح الساخن الوحيد** ولجوئك إلى التخزين المؤقت + التجزئة بدل "أضِف المزيد من replicas" (فالـ replicas توسّع القراءات لا هذه الكتابة). الجيد: "استخدم طابوراً وكاشاً." الرائع: تسمّي **مقايضة الاتساق النهائي** — الرقم الحيّ يتأخّر عن الواقع بثانية — وتُحاجج بأن ذلك مقبول لعدّ الأصوات لكن *ليس* للنتيجة النهائية المعتمَدة، التي تُعيد حسابها بشكل موثوق بعد إغلاق الاقتراع.

**فخّ شائع:** استخدام transaction لقاعدة البيانات لكل صوت "للدقّة". على هذا النطاق هذا هو ما ينصهر.

## المقايضات وأنماط الأعطال

- **الإحصاء النهائي:** مجاميع الأجزاء تتأخّر؛ مقبول لعدّاد حيّ، طابِقه عند الإغلاق.
- **تسليم At-least-once:** قد يُعيد Kafka التسليم — إزالة التكرار تجعل الزيادات idempotent، وإلا حسبت مرتين.
- **انحراف الجزء الساخن (Hot shard skew):** أجزاء قليلة جداً وتظلّ تتنافس؛ وكثيرة جداً فيصبح الجمع مُكلفاً. من 32 إلى 128 جزءاً هو المعتاد.
- **العدل/الاحتيال:** حُدّ المعدّل لكل IP/جهاز؛ مجموعة الصوت الواحد هي حدّ نزاهتك. فقدانها يعني حشو صناديق الاقتراع لا انهياراً — وهو أسوأ على الأرجح.

لماذا نخزّن الكتابات مؤقتاً

العدّادات المجزّأة تقتل النقطة الساخنة

إزالة تكرار الصوت الواحد

منظور المقابلة

المقايضات وأنماط الأعطال

أسئلة ذات صلة