تخطَّ إلى المحتوى

Community platforms

نموذج مرجعي

Fifty thousand concurrent voters without touching the database

A live polling platform that counts votes in Redis and flushes to PostgreSQL in batches — cutting database write load by 97% while acknowledging votes in under 20 milliseconds.

1M+votes processed

لمحة سريعة

المدة
35 أسبوعاً
حجم الفريق
3 أشخاص
نوع التعاقد
بناء جديد
نوع المشروع
تطبيق ويب
القطاع
الإعلام والترفيه

الوضع

التحدي

Naive vote counting collapses at scale: 50,000 concurrent voters means 50,000 simultaneous write transactions and COUNT queries against PostgreSQL. Multiple accounts and bots threatened the credibility of the results on top of that.

ما الذي فعلناه

Count where counting is cheap, persist on a schedule, and accept that the database being five seconds behind is invisible to everyone.

القرارات التي صنعت الفارق

  • Redis counts, PostgreSQL records

    INCR for O(1) tallying and SADD for deduplication, with Lua scripts making check-and-increment atomic. A five-second batch flush to PostgreSQL removed 97% of the write load.

  • Diff-based broadcasts on a fixed cadence

    500ms broadcasts carrying only what changed. Pushing full tallies per vote is what turns a popular poll into a self-inflicted denial of service.

ما الذي تغيّر

total votes processed
1M+total votes processed
concurrent voters
50Kconcurrent voters
p99 vote acknowledgement
<20msp99 vote acknowledgement
reduction in database write load
97%reduction in database write load
  • 50K — without degradation

A million votes processed, 50,000 concurrent voters held without degradation, sub-20ms acknowledgement, and no vote corruption incidents.

الخدمات المستخدمة

  • Redis-first vote counting with atomic Lua operations
  • Batched persistence layer and reconciliation
  • Layered anti-fraud: fingerprinting, rate limits, challenges

ما الذي كنا سنفعله بشكل مختلف

لكل مشروع واحدة من هذه. ونشرها هو المقصد — فدراسة حالة بلا ندم فيها تسويق لا دليل.

Scaling here was about accepting eventual consistency in the right place. The flush delay makes database records briefly stale, but users read results from Redis and perceive them as live — decoupling the two let each be optimised on its own terms.