5 ms·

I can't think of a better way to actually maintain a clear understanding of what's going on at a place like Shopify. Good memory: Lutke's blog is responsible f

I can't think of a better way to actually maintain a clear understanding of what's going on at a place like Shopify. Good memory: Lutke's blog is responsible for a lightbulb moment of mine back in 2007, regarding cache invalidation. The post is long gone, but it was entitled "The Secret to memcached" -- the advice, which is incredibly obvious in retrospect but wasn't to me at the time, is to manage cache invalidation by adding a unique ID to the cached asset, and letting the cache fill and expire items on its own. Going into it, I had assumed I should be removing cached items in the code that was utilizing the cache. I was ignorant. I still am, but less so about memcached. Thanks, Tobias!

dmarlow 6y ago
Thanks for sharing this. I've used this (I call it a cache buster) for static assets in a CDN, but never considered it for other things. I'd love to read the article if it can be dug up. It's not clear how that unique ID is managed and am curious to learn more.
craz8 6y ago
This technique is the way Rails Fragment Caching works, and enables Russian Doll caching Those terms should help you find more writing about this technique that I always forget isn’t obvious outside the Rails ecosystem
- mmahemoff 6y ago
  DHH helped to popularise it with this post: https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works https://signalvnoise.com/posts/3113-how-key-based-cache-expi... It's been hugely influential to the way I think about scaleable pages. It's a similar idea to the cache-busting techniques well-known with URLs (https://example.com?style.css=1234 https://example.com?style.css=1234 etc), but applied to page fragments recursively, where a change in any component also "revs"/"bumps" its parent components.
embit 6y ago
I think he was an active contributor to RoR in those days
christocracy 6y ago
He’s great. I used his Money (for managing money values as cents in the db), Liquid and DelayedJob in a bunch of projects. Now I run my own Shopify store, selling my software.
AVTizzle 6y ago
>> I can't think of a better way to actually maintain a clear understanding of what's going on at a place like Shopify. Talking to customers would be one better way to maintain said clear understanding. Running your own Shopify store (which Tobias also does) could potentially be another.
throw0101a 6y ago
> The post is long gone, but it was entitled "The Secret to memcached" The Internet (Archive) remembers: * https://web.archive.org/web/20120125060458/http://blog.leetsoft.com/2007/05/22/the-secret-to-memcached.html https://web.archive.org/web/20120125060458/http://blog.leets...
ehnto 6y ago
We call them cache keys. We use a hash of entirely arbitrary data you want a cache item to invalidate on when that data changes. For example, a cached snippet of HTML for a related products section should invalidate if the product IDs change, so you hash the Item ID with the product IDs and bam, you got a cache key that will let you know when you need to reprocess that snippet. Put that bad boy as a child of another snippet and you can cache the whole lot. It's cache keys all the way down! Caveat: not worth the engineering effort for simple systems, just use an FPC and call it a day.
- reidjs 6y ago
  FPC: Full Page Cache
  - ehnto 6y ago
    Yep, sorry I should have expanded that.
ashtonkem 6y ago
You can often go further than that with some database trickery. We once needed to cache a list of objects that was unacceptably slow serialize the JSON for. We needed to cache them in memcache, but also needed reliable cache invalidation without having to instrument every ingestion point with the logic. Here's what we ended up doing. 1. Every record gets an int field titled "index" or similar. 2. Every time a record is inserted or updated, index is changed to the next value from a sequence 3. The cache key for memcache includes the number of records and the maximum index from all the records returned (including any intermediate objects if joins are involved) 4. Infinite TTL for all cache keys, but the entire cache is LRU guaranteeing that stale records are eventually removed. This setup works because any conceivable operation done would change the cache key. If new records are inserted or deleted, count and index change. If a record is updated, then the max index changes. Even deleting and adding a new record will change the index, meaning that no matter what happens you'll get a new key and the system will continue to cache appropriately.
arcticbull 6y ago
I disagree completely. Once you're in a management role, let alone a CEO role, your job not to write software. You defer defer implementation and architecture completely to your team. Your job is to hire and build that team and set high-level company direction. The more power you have over your co-implementors' careers -- and the more junior they are -- the less comfortable they are standing up to your architectural or technical decisions. This stifling of collaboration can cause you to make poor decisions you wouldn't otherwise, and creates an uncomfortable dynamic. This is why I don't believe in TLM ("tech lead manager") roles, also, fwiw. Wanna code? Do it on your own time, Tobi! :)
- deleted 6y ago
  [deleted]
- ragebol 6y ago
  As CEO or CTO, it;'s crucial you understand your business and if you're in a tech business, you better understand the tech to an appropriate level too. Coding can be a part of that
- bertr4nd 6y ago
  I’ve only once worked under a manager who also coded, and I had extremely mixed feelings. On the one hand, he was a brilliant engineer who I learned a ton from, and who set a really solid technical direction for the team. On the other hand, I was personally unhappy a lot of the time. On one occasion he pretty much tore apart one of my designs and I felt fairly humiliated (with reason, as a few other senior engineers confirmed in private conversations). Did my design deserve to die horribly? I don’t know. The PR had already been accepted, but maybe the accepter was wrong. In any case it felt really crappy to be criticized so heavily by someone who in theory supports me.
  - arpa 6y ago
    You know, it's easy to be an asshole when you're brilliant. But that's why soft skills are important, especially in leadership roles. I tried my best to be a supporting lead, everywhere i was in that role. I believe in leading by example, but i recognize the necessity to _let_ people do things themselves and not just hog power because "i know best". Let people implement imperfect designs. They'll own it, learn, and fix them in time. Your job is to lead, to give direction and not let total crap be put into prod, not keep people under your "benevolent dictator" heel.
indysigners 6y ago
From inside of Shopify I’ve heard about a lot of shit stories. For their employees, it may be less ideal to have a CEO messing around with code. From the outside though, the company does extremely well. Nonetheless, CEOs are generally not supposed to „make“ but to manage. There has to be a tradeoff somehow.

dmarlow 6y ago

Thanks for sharing this. I've used this (I call it a cache buster) for static assets in a CDN, but never considered it for other things. I'd love to read the article if it can be dug up. It's not clear how that unique ID is managed and am curious to learn more.

craz8 6y ago

This technique is the way Rails Fragment Caching works, and enables Russian Doll caching Those terms should help you find more writing about this technique that I always forget isn’t obvious outside the Rails ecosystem

mmahemoff 6y ago
DHH helped to popularise it with this post: https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works https://signalvnoise.com/posts/3113-how-key-based-cache-expi... It's been hugely influential to the way I think about scaleable pages. It's a similar idea to the cache-busting techniques well-known with URLs (https://example.com?style.css=1234 https://example.com?style.css=1234 etc), but applied to page fragments recursively, where a change in any component also "revs"/"bumps" its parent components.

embit 6y ago

I think he was an active contributor to RoR in those days

christocracy 6y ago

He’s great. I used his Money (for managing money values as cents in the db), Liquid and DelayedJob in a bunch of projects. Now I run my own Shopify store, selling my software.

AVTizzle 6y ago

>> I can't think of a better way to actually maintain a clear understanding of what's going on at a place like Shopify. Talking to customers would be one better way to maintain said clear understanding. Running your own Shopify store (which Tobias also does) could potentially be another.

throw0101a 6y ago

> The post is long gone, but it was entitled "The Secret to memcached" The Internet (Archive) remembers: * https://web.archive.org/web/20120125060458/http://blog.leetsoft.com/2007/05/22/the-secret-to-memcached.html https://web.archive.org/web/20120125060458/http://blog.leets...

ehnto 6y ago

We call them cache keys. We use a hash of entirely arbitrary data you want a cache item to invalidate on when that data changes. For example, a cached snippet of HTML for a related products section should invalidate if the product IDs change, so you hash the Item ID with the product IDs and bam, you got a cache key that will let you know when you need to reprocess that snippet. Put that bad boy as a child of another snippet and you can cache the whole lot. It's cache keys all the way down! Caveat: not worth the engineering effort for simple systems, just use an FPC and call it a day.

reidjs 6y ago
FPC: Full Page Cache
- ehnto 6y ago
  Yep, sorry I should have expanded that.

ashtonkem 6y ago

You can often go further than that with some database trickery. We once needed to cache a list of objects that was unacceptably slow serialize the JSON for. We needed to cache them in memcache, but also needed reliable cache invalidation without having to instrument every ingestion point with the logic. Here's what we ended up doing. 1. Every record gets an int field titled "index" or similar. 2. Every time a record is inserted or updated, index is changed to the next value from a sequence 3. The cache key for memcache includes the number of records and the maximum index from all the records returned (including any intermediate objects if joins are involved) 4. Infinite TTL for all cache keys, but the entire cache is LRU guaranteeing that stale records are eventually removed. This setup works because any conceivable operation done would change the cache key. If new records are inserted or deleted, count and index change. If a record is updated, then the max index changes. Even deleting and adding a new record will change the index, meaning that no matter what happens you'll get a new key and the system will continue to cache appropriately.

arcticbull 6y ago

I disagree completely. Once you're in a management role, let alone a CEO role, your job not to write software. You defer defer implementation and architecture completely to your team. Your job is to hire and build that team and set high-level company direction. The more power you have over your co-implementors' careers -- and the more junior they are -- the less comfortable they are standing up to your architectural or technical decisions. This stifling of collaboration can cause you to make poor decisions you wouldn't otherwise, and creates an uncomfortable dynamic. This is why I don't believe in TLM ("tech lead manager") roles, also, fwiw. Wanna code? Do it on your own time, Tobi! :)

deleted 6y ago
[deleted]
ragebol 6y ago
As CEO or CTO, it;'s crucial you understand your business and if you're in a tech business, you better understand the tech to an appropriate level too. Coding can be a part of that
bertr4nd 6y ago
I’ve only once worked under a manager who also coded, and I had extremely mixed feelings. On the one hand, he was a brilliant engineer who I learned a ton from, and who set a really solid technical direction for the team. On the other hand, I was personally unhappy a lot of the time. On one occasion he pretty much tore apart one of my designs and I felt fairly humiliated (with reason, as a few other senior engineers confirmed in private conversations). Did my design deserve to die horribly? I don’t know. The PR had already been accepted, but maybe the accepter was wrong. In any case it felt really crappy to be criticized so heavily by someone who in theory supports me.
- arpa 6y ago
  You know, it's easy to be an asshole when you're brilliant. But that's why soft skills are important, especially in leadership roles. I tried my best to be a supporting lead, everywhere i was in that role. I believe in leading by example, but i recognize the necessity to _let_ people do things themselves and not just hog power because "i know best". Let people implement imperfect designs. They'll own it, learn, and fix them in time. Your job is to lead, to give direction and not let total crap be put into prod, not keep people under your "benevolent dictator" heel.

indysigners 6y ago

From inside of Shopify I’ve heard about a lot of shit stories. For their employees, it may be less ideal to have a CEO messing around with code. From the outside though, the company does extremely well. Nonetheless, CEOs are generally not supposed to „make“ but to manage. There has to be a tradeoff somehow.