One Million Checkboxes को 65 करोड़ checks तक scale करने की तकनीक

 (eieio.games)
1 पॉइंट द्वारा GN⁺ 2024-07-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 26 जून 2024 को सार्वजनिक किया गया One Million Checkboxes एक ऐसी साइट थी जहाँ सभी लोग समान 10 लाख checkboxes को real time में manipulate करते थे, और 2 हफ्ते बाद बंद होने से पहले इसने 65 करोड़ से ज़्यादा checks process किए
  • state खुद सिर्फ 10 लाख bits, यानी 125KB की थी, लेकिन nginx, Flask/gunicorn और Redis pubsub से बनी शुरुआती structure अप्रत्याशित traffic के सामने जल्दी ही अपनी सीमा तक पहुँच गई
  • Hacker News, Reddit, Mastodon और Twitter से दसियों हज़ार लोग आने लगे तो Redis connections खत्म होना, bandwidth का तेज़ी से बढ़ना, input validation की कमी और पुराने updates apply होने जैसी समस्याएँ एक के बाद एक सामने आईं
  • response में servers और Redis को scale करना, updates की batch processing, transfer format को छोटा करना, Linux tc आधारित 250Mbit/s bandwidth cap, और process restart scripts जैसे जल्दी लागू किए जा सकने वाले उपायों पर focus किया गया
  • बाद में backend को Go में move करके stabilize किया गया, और अंत में Redis Lua script से checkbox freeze logic को atomic तरीके से process कर साइट 11 जुलाई 2024 को Eastern Time 4:35 PM पर समाप्त हुई

साइट और शुरुआती design

  • One Million Checkboxes(OMCB) 26 जून 2024 को launch की गई एक website थी, जो 10 लाख global checkboxes उपलब्ध कराती थी
    • कोई user checkbox को on या off करता तो यह सभी users की screen पर तुरंत दिखता
    • इसे बनाने में 2 दिन लगे, और expected users अधिक से अधिक कुछ सौ के स्तर पर थे
  • असल response उम्मीद से कहीं बड़ा था
  • पहले दिन के शुरुआती logs कुछ हद तक बचे नहीं हैं
    • क्योंकि शुरुआत में एक दिन के logs में सिर्फ नवीनतम 10 लाख entries रखी जाती थीं
    • दूसरे दिन से stabilization शुरू हुआ, और उस दिन 5 करोड़ से ज़्यादा checks हुए
    • साइट बंद होने से पहले cumulative check count 65 करोड़ से अधिक हो गया

Redis-केंद्रित original architecture

  • checkbox state को 10 लाख bits में represent किया गया
    • checked box 1, unchecked box 0
    • पूरी state का size 125KB था
    • client bitset को store करता और rendering के समय उसे reference करता
  • client को DOM load से बचने के लिए configure किया गया
    • 10 लाख elements को पूरा DOM में नहीं डाला गया
    • react-window का इस्तेमाल करके वर्तमान screen पर दिख रहे checkboxes और छोटे buffer को ही render किया गया
  • server setup simple horizontal scaling को ध्यान में रखकर बनाया गया था
    • nginx static content serve करता और API requests व websocket connections को Flask server तक forward करता
    • Flask server gunicorn से चलने वाली दो instances थीं
    • Redis checkbox state storage और message queue की भूमिका निभाता था
  • Redis का इस्तेमाल भी सीधा था
    • Redis के bit manipulation primitives से individual checkbox state बदली जाती थी
    • client check event भेजता तो Flask Redis का bit flip करता और pubsub में event record करता
    • दोनों Flask servers pubsub पढ़कर अपने connected clients को changes notify करते
  • पूरा state snapshot updates miss होने की भरपाई के लिए एक mechanism था
    • यह उन clients को sync करने के लिए था जिनके tabs background में होने के कारण updates miss कर देते थे
    • शुरुआती implementation हर 30 सेकंड में पूरी state भेजने वाली थी

scaling principles

  • cost का upper bound calculate किया जा सकना चाहिए था
    • unlimited auto scaling से cost explode होने वाले तरीके से बचा गया
    • उम्मीद से अधिक load आने पर टूट जाने देने वाला रास्ता चुना गया
  • popularity की duration छोटी मानी गई
    • कुछ दिनों या हफ्तों वाली polished solution की बजाय कुछ घंटों में बनाए जा सकने वाले responses को priority दी गई
    • उस process में बनने वाला technical debt स्वीकार किया गया
  • technology choices में simple और सीधे operate की जा सकने वाली चीज़ों को preference दिया गया
    • ऐसा setup चुना गया जिसमें server पर directly connect होकर commands चला सकें और debug कर सकें
    • mainly ऐसी dependencies इस्तेमाल की गईं जिन्हें खुद operate और debug किया जा सके
  • साइट का core experience global synchronization था
    • कहीं भी जाएँ, immediate changes दिखने चाहिए थे
    • सिर्फ user द्वारा देखे जा रहे checkboxes भेजने वाले तरीके से scale नहीं किया गया

पहला दिन: servers बढ़ाना और Redis bottleneck

  • launch के 30 मिनट के भीतर load तेज़ी से बढ़ा, और साइट चल रही थी लेकिन लंबे समय तक टिकना मुश्किल लग रहा था
    • सबसे स्पष्ट सुधार servers बढ़ाना था
    • nginx दूसरे VM की Flask instances तक आसानी से reverse proxy कर सकता था, और state पहले से Redis में थी
  • दूसरा server लगभग 12:30 PM पर जोड़ा गया और जल्द ही load 100% तक पहुँच गया
    • शुरुआत में लगा कि एक-दो servers और जोड़ना काफी होगा
    • असल में scaling के साथ traffic भी बढ़ता गया
    • Hacker News पर यह #1 पर पहुँचा और Twitter activity भी तेज़ी से बढ़ी
  • Flask servers और Redis connections bottleneck बन गए
    • Redis connection pool नहीं था और Redis connection shortage के करीब पहुँच रहा था
    • updates को batch में जोड़कर भेजने के तरीके पर switch किया गया
    • existing clients के साथ compatibility पर विचार नहीं किया गया, माना गया कि users refresh करेंगे
  • Redis connection pool भी जोड़ा गया, लेकिन gunicorn और Flask combination में यह साफ़-सुथरे तरीके से काम नहीं कर रहा था
    • फिर भी Redis connections की संख्या घटाने में मदद मिली लगती है
    • बाद में इस समस्या को गहराई से खोदने के बजाय Go migration पर बढ़ गए
  • session creation rate limit हटाई गई
    • rate limit state Redis में store थी और Redis connections खत्म हो रहे थे
    • समस्या new sessions की बाढ़ नहीं, बल्कि single session से बहुत data भेजने की तरफ थी
    • short term में risky, लेकिन acceptable measure माना गया
  • Redis instance को भी बड़े specs पर upgrade किया गया
    • Digital Ocean managed Redis इस्तेमाल हो रहा था
    • 1 shared CPU, 2GB RAM वाले छोटे instance से 4 dedicated CPU, 32GB RAM instance पर बढ़ाया गया
    • resize में करीब 30 मिनट लगे

bandwidth समस्या और transfer volume घटाना

  • शुरुआत में bandwidth cost पर पर्याप्त विचार नहीं किया गया था
    • Digital Ocean free bandwidth से अधिक होने पर प्रति GB $0.01 charge करता है
    • पिछले काम से 1TB free bandwidth थी, और लगा कि OMCB का बड़ा असर नहीं होगा
  • full state snapshots bandwidth तेज़ी से खा सकते थे
    • 10 लाख bits यानी 1Mbit
    • हर 30 सेकंड में 1,000 लोगों को भेजें तो लगभग 2GB प्रति मिनट, 120GB प्रति घंटे के स्तर पर पहुँचता है
    • यह संख्या incremental updates को ध्यान में रखे बिना है
  • bandwidth check और cost cap setting nginx box पर की गई
    • ip -s link show dev eth0 से भेजे गए bytes की संख्या check की गई
    • single nginx reverse proxy इस्तेमाल होने से bandwidth source infer करना आसान था
  • transfer volume कम करना दो दिशाओं में चला
    • full state snapshot की frequency घटाई गई
    • incremental update format को छोटा किया गया
  • batch update format काफी compress हुआ
    • पुराना format { "index": 123, "value": true } जैसी dict list था
    • final format true index array और false index array की pair, यानी [[123, 125], [124]] के रूप में था
    • यह तरीका original implementation से 5 गुना छोटा था
  • Linux tc से hard cap लगाकर cost runaway रोकी गई
    • public interface eth0 के traffic को 250Mbit/s तक limit किया गया
    • यह लगभग 2GB प्रति मिनट, और दिन में 3TB से थोड़ा कम के स्तर का है
    • प्रति GB $0.01 के हिसाब से रातोंरात cost uncontrollable होने से बच सकती थी

दूसरा दिन: input validation की कमी और Redis replica

  • अगली सुबह साइट down थी, और वजह input validation की कमी थी
    • 10 लाख से अधिक index वाले checkboxes को block नहीं किया गया था
    • किसी ने करोड़ों के index वाले checkboxes manipulate किए
    • इससे ऐसा लगा कि checked boxes की संख्या 10 लाख तक पहुँच गई है और साइट खत्म हो गई है
  • Redis data भी बेवजह बड़ा हो गया
    • 10 लाखवें bit और 10 करोड़वें bit के बीच लाखों 0 जुड़ गए
    • client को भेजा जाने वाला data 100 गुना बड़ा हो गया
  • recovery तेजी से हुई
    • nginx रोका गया
    • existing bitset के पहले 10 लाख bits को नए bitset में copy किया गया
    • पुराने bitset को debugging के लिए preserve किया गया
    • code को नए bitset reference करने के लिए बदला गया और input validation जोड़ी गई
  • initial page load भी slow हो गया था
    • Redis पर load ज्यादा था और connection pool bug के कारण connections भी जरूरत से ज्यादा बन रहे थे
    • connection pool issue debug करने के बजाय Redis replica जोड़कर primary load और connections distribute किए गए
  • replica का private IP manually ढूँढना पड़ा
    • Digital Ocean guide के अनुसार public DNS में replica- prefix काम करता था, लेकिन private DNS में नहीं
    • public IP इस्तेमाल करने पर public internet route और bandwidth charge का risk माना गया
    • primary और अन्य servers के private IPs के आसपास addresses पर connect करने की कोशिश की और तीसरे या चौथे attempt में replica private IP मिल गया
    • इसके बाद उस IP को hardcode किया गया

process restart और stale update fix

  • Flask processes लगातार crash हो रहे थे, और वजह Redis connection shortage लग रही थी
    • detailed debugging की बजाय running Flask processes की संख्या check करने वाली bash script बनाई गई
    • अगर running processes 3 से कम हों तो systemd unit restart किया गया
    • script को crontab में डाला गया
  • nginx configuration भी साथ में adjust की गई
    • down servers को कुछ समय के लिए rotation से exclude करने के लिए बदला गया
    • इस change के बाद साइट stabilize हुई
  • client state synchronization में stale update bug था
    • client incremental updates और full-state snapshot दोनों receive करता था
    • दोनों updates में timestamp नहीं था, इसलिए नया snapshot मिलने के बाद पुराना incremental update apply हो सकता था
    • नतीजतन अगले full-state snapshot तक पूरी तरह गलत state दिख सकती थी
  • timestamp-based mitigation जोड़ी गई
    • full-state snapshot में timestamp लगाया गया
    • Redis pubsub में record किए जाने वाले हर update में भी timestamp लगाया गया
    • client को भेजे जाने वाले batch में included incremental updates में से maximum timestamp डाला गया
    • client को last full-state snapshot से पुराने batches discard करने के लिए बदला गया
  • यह solution perfect नहीं था
    • batch के अंदर अगर एक भी नया update हो, तो भले ही ज्यादातर updates पुराने हों, वे apply हो सकते थे
    • फिर भी पहले से काफी बेहतर था

Go rewrite और stabilization

  • अगली सुबह साइट live थी, और फिर backend rewrite पर focus किया गया
    • Washington Post से email भी आ चुकी थी
    • साइट को कैसे end करना है, इसकी planning भी साथ में सोची गई
  • closure plan ऐसा था कि checked boxes जल्दी unchecked न हों तो freeze हो जाएँ
    • यह change activity spike और अतिरिक्त server work trigger कर सकता था
    • existing Flask-based structure इसे संभाल पाएगी या नहीं, इसका भरोसा नहीं था
  • दोस्त Eliot के साथ backend को Go में फिर से लिखा गया
    • रविवार 2 PM से 2 AM तक implementation पर discussion किया गया और पूरा backend port किया गया
    • structure को बहुत बदले बिना move किया गया
    • latest protocol support करने वाली Go socketio library ढूँढने जैसी चीजें hurdles थीं
  • performance improvement बहुत बड़ा था
    • इतना अच्छा scale हुआ कि bots अत्यधिक traffic push कर सकते थे
    • बेहतर rate limit की जरूरत हो गई
  • रविवार रात DDoS भी हुआ
    • साइट को Cloudflare के पीछे रखकर और nginx config थोड़ा बदलकर response दिया गया

साइट closure logic

  • Go rewrite के बाद साइट stable तरीके से चली
    • इसके बाद एक हफ्ते तक interviews और interest को handle किया गया
    • फिर साइट closure work शुरू हुआ
  • closure method checkbox freezing था
    • checked box अगर जल्दी unchecked नहीं होता तो frozen state में चला जाता
    • समय बीतने पर पूरी साइट पूरी तरह frozen state में हो जाती
  • Redis में additional state जोड़ी गई
    • हर checkbox आखिरी बार कब checked हुआ, यह store करने के लिए hashtable जोड़ा गया
    • client को भेजने के लिए यह state बड़ी थी, लेकिन Redis में store करने के लिए ठीक थी
    • time_to_freeze value भी store की गई
  • uncheck के समय freeze status decide किया गया
    • अगर now - last_checked > time_to_freeze हो तो uncheck नहीं किया गया
    • इसके बजाय frozen_bitset update करके उस checkbox को frozen state में mark किया गया
    • frozen_bitset checked state की तरह ही clients में distribute किया गया
    • client frozen bit on वाले checkboxes को disable करता था
  • कोई uncheck न करे तब भी freeze हो, इसके लिए अलग job जोड़ी गई
    • periodic रूप से उन bits को खोजा गया जिन्हें freeze होना चाहिए लेकिन अभी mark नहीं किया गया था, और उन्हें frozen state में बदला गया
    • संबंधित logic Redis Lua script में डालकर atomic रूप से execute किया गया
    • race condition से बचना आसान था
  • closure change launch के 2 हफ्ते 1 दिन बाद apply हुआ
    • 11 जुलाई 2024 को Eastern Time 4:35 PM पर box 491915 checked हुआ और साइट समाप्त हुई

cost और सीख

  • साइट चलाने की cost लगभग $850 थी
    • donations इस cost के काफी करीब पहुँच गईं
    • निष्कर्ष निकाला कि यह बड़ा नुकसान नहीं था
  • Redis और nginx के choice से संतुष्टि रही
    • Redis और nginx को बहुत उपयोगी technologies माना गया
    • खुद operate करने से debugging और fixes आसान रहे
    • हालांकि managed Redis instance पर पूरा control न होना थोड़ा असुविधाजनक था
  • शुरुआत से लंबे समय तक large-scale expansion design न करने के decision को सकारात्मक माना गया
    • माना गया कि internet पर क्या चलेगा, predict करना मुश्किल है
    • अगर शुरुआत से ही कई हफ्ते scale पर सोचते रहते, तो शायद launch नहीं हो पाता
    • बहुत users आना maintenance motivation और priority setting में मददगार रहा
  • सीमित anonymous interaction की demand भी दिखी
    • strangers के साथ limited तरीके से interact करने वाली sites में लोगों ने interest दिखाया
    • ऐसी sites बनाते रहने का confidence बढ़ा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-07-28
Hacker News की रायें

  • distributed systems के ऐतिहासिक ज्ञान के साथ यह सीखने लायक बहुत कुछ वाला लेख था
    storage को छोड़ दें तो लगता है लगभग हर तरह के outage और failure point का सामना किया, और समाधान की प्रक्रिया देखना अच्छा लगा
    मुझे नहीं पता था कि Redis Lua सपोर्ट करता है; यह देखकर इसे वैकल्पिक state store के तौर पर आज़माने का मन हुआ
    bandwidth cloud services को लेकर मेरी सबसे बड़ी शिकायतों में से एक है, क्योंकि bill बढ़ने से रोकने के लिए कोई hard limit नहीं होती

    • storage की समस्या भी आई थी, बस उबाऊ तरीके से। logrotate ठीक से configure नहीं था, इसलिए disk लगभग भर गई थी, और box-check logs Redis में भेजते समय Redis फट न पड़े, इसके लिए पुराने logs को disk पर उतारने की व्यवस्था बनानी पड़ी
      हालांकि दोनों बड़ी समस्याएँ नहीं थीं, और यह काफी दिलचस्प था कि इस project में storage कोई सार्थक समस्या नहीं बना। मेरे लिए निजी तौर पर यह नया अनुभव था
      bandwidth सचमुच सिरदर्द था। करीब दो दिन तक तनाव में NIC के transmit bytes देखते और हिसाब दोबारा लगाते रहे, और hard cap न होना डरावना था। Digital Ocean के दाम काफी reasonable होने के बावजूद ऐसा था
      मैंने लोकप्रिय serverless services इस्तेमाल नहीं की हैं, लेकिन मेरी समझ में वहाँ bandwidth cost काफी जोर से लगती है
      और Redis के अंदर Lua वाकई शक्तिशाली है; अगर थोड़ा performance loss स्वीकार कर सकते हैं, तो मुश्किल और race condition वाली कई समस्याओं को टाला जा सकता था, और उसके साथ काम करना मज़ेदार था

  • शानदार लेख था और website भी बधाई के काबिल है
    लेकिन निजी तौर पर मुझे लगता है कि यह लिखा गया लेख ही सबसे ज़्यादा गर्व करने लायक हिस्सा है

    • launch से पहले site बनाने में जितना समय लगाया, उससे कहीं ज़्यादा समय लेख लिखने में लगाया, और यह बात काफी मज़ेदार लगती है

  • मेरे हिसाब से मुख्य बात यह थी कि “scalability की लगभग परवाह किए बिना दो दिन में site बनाना अच्छा फैसला था”
    खासकर career की शुरुआत में मौजूद engineers को यह सीखना चाहिए। Scalability तब तक समस्या नहीं है जब तक वह सच में समस्या न बन जाए
    जब वह समस्या बनती है, तब वह बल्कि अच्छी समस्या होती है, और उसे ठीक करना अक्सर उतना कठिन भी नहीं होता जितना लगता है

    • यह बात तभी सही है जब इसके साथ “इसलिए system को simple और basic रखें” वाली बात भी मानें
      मैंने ऐसे कई systems देखे हैं जहाँ microservices इसलिए “obvious choice” बन गईं कि developers बस ऐसा करना चाहते थे, न कि scaling या team separation के लिए
      ऐसे systems को scale करना सचमुच यातना है

  • हाल का संबंधित लेख: One Million Checkboxes - https://news.ycombinator.com/item?id=40800869 - जून 2024, 305 comments

  • ऐसे projects मज़ेदार होते हैं
    करीब 6 साल पहले Android पर Pixmap launch किया था, यह एक छोटी collaborative pixel editing app थी जो 1024x1024 जैसे बड़े grids को support करती थी
    हर event को PNG image पर apply करने वाली queue रखी थी, और client connection पर initial PNG load करता था, फिर हर pixel drawing event के लिए बस एक छोटा object प्राप्त करता था
    इससे initial load में image compression का फायदा मिलता है, और बाद के change sets बहुत छोटे हो जाते हैं। साथ ही सभी events log में stored होते हैं, इसलिए image को “rewind” भी किया जा सकता है [0]
    [0] 22mb: https://blog.winricklabs.com/images/pixmap-rewind-demo.gif

    • बढ़िया। कई web clients को pixel-level updates भेजने का ऐसा ही idea देखा था, लेकिन मेरे सोचे तरीके में bandwidth और storage बहुत ज़्यादा लगते
      इसलिए मैं API calls से address किए जा सकने वाले canvas के साथ प्रयोग कर रहा हूँ
      https://x.com/RussTheMagic/status/1816749136487588311

  • अच्छा लेख था। आखिर में कुल खर्च कितना आया यह जानने की उत्सुकता है

    • यह बात शामिल करनी चाहिए थी
      कुल cost लगभग 850 डॉलर थी, और donations से लगभग पूरी cover हो गई
      Go पर move करने के बाद infra सही से बंद न करना मेरी गलती थी, और अतिरिक्त चलाए गए दूसरे Redis replica को भी हटाया जा सकता था। अगर cost पर focus करता तो शायद इसे आधा कर सकता था
      लेकिन donations लागत को लगभग cover कर रही थीं और बहुत सारी दूसरी चीज़ें चल रही थीं, इसलिए इस पर बहुत ध्यान नहीं दिया
      site बंद करने के बाद भी graphs तैयार करने आदि के लिए infra कुछ समय तक रखा, इसलिए थोड़ा और पैसा लगा, और अभी हल्का घाटा है लेकिन बड़ा नहीं

  • backend नया सीख रहे व्यक्ति के तौर पर, सोच रहा हूँ कि क्या इस project के लिए कोई और simple alternative architecture हो सकता है
    10 लाख bit states host करके clients के साथ sync करने का आसान तरीका हो तो अच्छा होगा। लेख के कुछ समाधान समझना कठिन था
    लेखक के projects शानदार हैं

    • अगर लेख के कुछ हिस्से कठिन लगे तो माफ़ी
      इस्तेमाल की गई technologies को और लंबा समझाना चाहता था, लेकिन लेख पहले से बहुत लंबा था इसलिए लगा और जोड़ना मुश्किल होगा
      सवाल हों तो खुशी से जवाब दूँगा
      ईमानदारी से कहूँ तो architecture को बहुत ज़्यादा simple करने का तरीका मुझे साफ़ नहीं दिखता। ऐसी services होंगी जिन्हें इस काम के लिए इस्तेमाल किया जा सकता है, लेकिन वह complexity किसी और पर डालने जैसा है
      अंत में जो चाहिए वह है checked boxes track करने वाला database, data को database में डालने का तरीका, current state clients को बताने का तरीका, client ने box check किया तो server को बताकर state update करने का तरीका, box check या uncheck होने पर clients को notify करने का तरीका, और हर समय 10 लाख DOM elements render न करने का तरीका
      यहाँ Redis से check state store की गई, simplicity के लिए पूरे 10 लाख bits वैसे ही store किए गए, और clients को पूरे 10 लाख bits भेजे गए। data बहुत बड़ा नहीं था, इसलिए यह ठीक रहा
      Flask और WebSocket से check events और updates handle किए गए, individual box updates और पूरे 10 लाख box updates दोनों भेजे गए, और rendering problem से बचने के लिए react-window इस्तेमाल किया गया
      बाकी nginx static content और reverse proxy मुख्य रूप से scaling आसान करने के उपाय थे, इसलिए उन details के बिना भी implementation संभव है और site चलती है। हालांकि वह उतना load नहीं संभाल पाएगी
    • लेख में बताई गई सारी चीज़ों को single process में भी ठूँसा जा सकता है
      database की जगह bit set को file में store करके mmap कर सकते हैं। reverse proxy की जगह application खुद HTTP requests और WebSocket connections handle कर सकती है
    • ईमानदारी से यह लगभग सबसे simple ही है
      पीछे cache और publish/subscribe queue के साथ कुछ web servers की configuration है
      एक बड़े host पर सब कुछ memory में ही process किया जा सकता था, लेकिन demand पूरी न हुई या किसी भी वजह से fail हुआ तो पूरी तरह अटक जाता
    • सच कहूँ तो इससे बहुत ज्यादा simple होना मुश्किल है
      सिवाय backend API वाले उसी process में 10 लाख boolean की global list रखने जैसे non-scalable तरीके के
    • समान state वाले checkbox blocks को (checked, start_x, start_y, end_x, end_y) tuples में summarize करने के लिए quadtree इस्तेमाल कर सकते हैं। क्या यह बहुत obvious तरीका नहीं है

  • शानदार
    सोच रहा हूँ कि अगला लेख इस पर statistical analysis होगा कि कौन-से checkboxes सबसे कम या सबसे ज्यादा check हुए
    मुझे याद है कि बहुत नीचे scroll करके चुना गया checkbox लगभग तुरंत uncheck हो गया था, जिससे थोड़ा दुख हुआ था

    • जल्द ही raw data share करने वाला हूँ
      उससे पहले site के बारे में एक और कहानी बतानी है

  • सोच रहा हूँ game अभी भी live है या नहीं
    https://onemillioncheckboxes.com/ पर जाने पर कुछ भी checked नहीं दिखता, और JS console में बस यह दिखता है
    {"total":0,"totalGold":0,"totalRed":0,"totalGreen":0,"totalPurple":0,"totalOrange":0,"recentlyChecked":false}

    • मूल लेख के अनुसार “2 हफ्ते बाद site बंद करने से पहले यह 65 करोड़ से आगे निकल गया था”

  • scalable implementation के ठीक उलटे उदाहरण के तौर पर, 1000 characters से कम में 10 लाख checkboxes का implementation है। Deno version
    https://gist.github.com/jeff-hykin/4cdebafd8698298d021f103e2...