We had an incident yesterday. It wasn’t that bad as incidents go, but it got me really worried — it’s something that has the potential to become much worse as we move towards a distributed, multi-service world.
Hi! I'm Julien "mezis" Letessier.
I'm a software geek: I build things with code, like web applications, platform tools, search engines, or even tiny crypto utilities.
I've had fun as an engineer, scientist, architect, manager, and start-up founder.
This is where I share about code craftsmanship, agile methods, and other random stuff I get excited about.
We had an incident yesterday. It wasn’t that bad as incidents go, but it got me really worried — it’s something that has the potential to become much worse as we move towards a distributed, multi-service world.
Counting unique users, checking if a credit card has already been used, or checking if this is a mobile user’s first visit ever — all of these require maintaining a large set of fingerprints (unique visitor ID, card fingerprint, IDFVs depending on the use case).
Because this usually needs to be queried very rapidly, Redis is naturally our store of choice. While using its SET feels obvious, what data structure to select? Are there memory/performance compromises?
This shows that while plain key/value is a safe bet, there are possible optimisations with hashes and traps to avoid with sets and sorted sets.
Split testing is a cornerstone of how we improve our products. While we usually run such tests for user-visible interface changes, this is an example of running a (successful!) multivariate test between CDNs.
The outcome is a 7% improvement in asset load times globally, translating into a +1% conversion on our site.