I wonder how the Fastly crew feels about all this. Great team over there, and they were originally the super configurable CDN, but it seems that is now completely beaten by Workers.
Introducing Workers KV
71–80 of 103 posts
Re: Introducing Workers KV
#72Great job - was trying to something similar by setting up three etcd raft nodes on each continent, but this is like 150+ nodes. Mind sharing of you’re using good clocks, paxos or raft to coordinate? Would also be great if CF could do websocket / sse fanout at the edges - if I have a couple million websockets connected on ws.cf.com/key1 and I update the value, would be great if the new value could be broadcast. That w…
Can you talk more about your specific use case?
The simplest example is liveblogging - someone is sitting at the next iPhone launch, and sending out photos and commentary that's being updated as they send on a large number of readers' screens worldwide. The Verge has a good system that they do with polling S3 for new data, but there's really much more effective ways to do it.
The more specific cases include opening ticket sales for movies in India - for some big movies tickets are sold out really quickly, so there'll be hundreds or thousands of people with browsers / phones open on a seat layout and they all need to see which seats are being sold in real-time.
Then there's broadcasting stock market movements and tips to thousands of traders in real-time.
The only existing solutions that seem really scalable are fanout.io - others like pusher.com and pubnub.com have pricing that's not conducive to serving a large number of simultaneous users / broadcasting. Fanout.io gets this right, but would be nice to have cheaper alternatives / make it a commodity.
Given that the CF nodes do support websockets, I assume they terminate and re-create new connections to origins as well - so the nodes are capable of holding a large number of websockets open, right? Can Workers intercept websockets / stream data into them? And given that the KV store is capable of propagating new values to all the nodes, there could be a way expose incoming change notifications on keys, which would handle this use case. Could also implement as continuous addition of new timestamps keys, prefixed with a topic.
Re: Introducing Workers KV
#73Earlier quoted context omitted.
Can you talk more about your specific use case?
The simplest example is liveblogging - someone is sitting at the next iPhone launch, and sending out photos and commentary that's being updated as they send on a large number of readers' screens worldwide. The Verge has a good system that they do with polling S3 for new data, but there's really much more effective ways to do it. The more specific cases include opening ticket sales for movies in India - for some big m…
Fundamentally what I think we want to do is build the primitives you would need to create your own fanout. That means we need the ability to push events to Worker nodes, and for Workers to be able to terminate WebSockets for you.
If you can accept up to 10s of latency, I agree that KV could solve the 'pushing events' problem for you. (A tuple store is semantically equivalent to message passing, and it will get easier when we support range queries).
Re: Introducing Workers KV
#74Earlier quoted context omitted.
So why not strong eventual consistency and CRDTs? As they fit perfectly for such functions running on edge nodes and no silly limitations of 1 write per second necessary.
Indeed. This is just stage 1 of our storage plans. We have some really cool stuff in the works but we wanted to get basic KV functionality out there for people to start using ASAP.
OT: we need to read more about your website-in-kv-thingy setup.
Re: Introducing Workers KV
#75I'm curious but I haven't seen anything about cache expiration on keys. Eg Expire all keys 'key-1' after 30 minutes or expire at a globally recognized time frame.
Does anyone know if this is possible?
Re: Introducing Workers KV
#76I'm curious but I haven't seen anything about cache expiration on keys. Eg Expire all keys 'key-1' after 30 minutes or expire at a globally recognized time frame. Does anyone know if this is possible?
We haven't exposed it yet, but it's implemented internally. Follow our blog and we'll update you when it's released.
Re: Introducing Workers KV
#77Earlier quoted context omitted.
Thanks, I misunderstood that part... very cool indeed. What are the overhead limits for workers? Aside, it seems like this could be really interesting combined to make an entire API with static delivery from S3 or Azure Blobs, with a backend on a cloud hosted database. With a lot of flexibility in between.
The ultimate goal is to let you do all of that within our network! When you say overhead limit, are you talking about latency? Our goal is to keep reads on the order of 5ms in the 90th percentile.
I mean compute/memory for the workers... just a rough comparison of what that might look like. Will probably sign up for the early access and play around with it soon.
Re: Introducing Workers KV
#78I'm curious but I haven't seen anything about cache expiration on keys. Eg Expire all keys 'key-1' after 30 minutes or expire at a globally recognized time frame. Does anyone know if this is possible?
We haven't exposed it yet, but it's implemented internally. Follow our blog and we'll update you when it's released.
Awesome, I'll be sure to keep up on that.
Re: Introducing Workers KV
#79Earlier quoted context omitted.
The simplest example is liveblogging - someone is sitting at the next iPhone launch, and sending out photos and commentary that's being updated as they send on a large number of readers' screens worldwide. The Verge has a good system that they do with polling S3 for new data, but there's really much more effective ways to do it. The more specific cases include opening ticket sales for movies in India - for some big m…
Fundamentally what I think we want to do is build the primitives you would need to create your own fanout. That means we need the ability to push events to Worker nodes, and for Workers to be able to terminate WebSockets for you. If you can accept up to 10s of latency, I agree that KV could solve the 'pushing events' problem for you. (A tuple store is semantically equivalent to message passing, and it will get easier…
Yes, both points make sense. And I assume the 10s latency is also geographically related - i.e. it's worst case 10s for the longest distance on the network topology graph? That should be fine.
Low latency requirements also tend to be geographical, I think - stock markets are mostly specific to a single country, examples like ticketing are usually specific to a single city / edge. For general news being broadcast globally, that kind of latency is fine.
Re: Introducing Workers KV
#80Holy return of tuple spaces! Are there any features for controlling consistency, or is it just YOLO last write wins?
I had to upvote you just because I plan on getting some mileage out the phrase "YOLO last write wins." It has just the right amount of snark to remind junior developers to not trivialize or discount the value of consistency.
And it's really "YOLO last write recorded wins," because who knows what order anything arrives in.