KV vs DO for link shortening
Ok thanks. Every request activates for 30s, if I understand correctly. Makes sense. Then after reading through the docs I can see that the recommendationis to not use single global objects, so I think "object per link entity" would be the way to go here. I still struggle to wrap my head around why/how Durable Objects are the best fit for this use case. They're certainly cool and powerful, but I don't really need all the extra guarantees. All I'd really need is a bit of a narrower windows for eventual consistency in KV. I think not having a TTL and the first lookup being "a bit slow" are both real downsides for me, albeit both would be acceptable. I'm mainly worried about the complexity here... KV is very simple to grasp, whereas DO is quite complex conceptually, even when misused as a key-value store
3 Replies
Lots of folks are building url shortening apps, and they ok with the default 60s ttl, because that’s the tradeoff for minimizing latency globally. Can you elaborate more on why the 60s min ttl is a hard requirement?
The reason is that it's not quite an URL shortener. Reads at the source are somewhat expensive, so they need to be minimized/cached. Writes are very infrequent, but when they happen, they need to be visible soon (around 60s, maybe a little bit longer). In other words, the TTL for the read cache should be higher than what is acceptable for the visibilty of updates. I know that this is solvable by a two-tier caching system, but of course that increases the overall system complexity. Less moving parts is better, so I was hoping that KV has a way to cache bust or sync in the background within a period that's acceptable for this use case
I still think KV would be a good option (with the default cacheTtl of 60s, which dictates how KV should cache & preiodically revalidate the value within the CF network) and will minimize the reads at your source.