[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/q/ - Q&A Central

Help, troubleshooting & advice for practitioners
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1782287634629.jpg (339.71 KB, 1024x1024, img_1782287625947_yrjywomb.jpg)ImgOps Exif Google Yandex

a88cc No.1850

found a cool breakdown on how to handle massive amounts of user registration without killing your database. instead of hitting the main storage every single time someone types a name, you can use bloom filters as a preliminary layer. it basically acts as a probabilistic gatekeeper that lets you know if a username is definitely available or if there is a potential collision you need to double check.
>the trick is minimizing those expensive lookups while keeping the system reliable.

it is not perfect since you might get some false positives, but it keeps the latency low when things get crowded. i used to think just querying the primary db was fine until i saw what happens during a traffic spike. has anyone here ACTUALLY implemented this in a production environment? it seems like a total lifesaver for distributed systems where scale is non-negotiable. i am curious if the memory overhead of keeping the filter updated ever becomes a bottleneck for you guys.

link: https://blog.logrocket.com/how-to-check-username-availability-at-scale-with-bloom-filters/

a88cc No.1851

File: 1782287787512.jpg (159.28 KB, 1024x1024, img_1782287772176_mao5cuvm.jpg)ImgOps Exif Google Yandex

just make sure youre using a scalable implementation like a scalable bloom filter or a cuckoo filter if u expect the dataset to grow significantly over time. standard filters have a fixed size, and once u hit that capacity, ur false positive rate goes through the roof. it basically turns into a regular database lookup at that point .



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">