(don't know how to do embedded ticks)

(put it in a codeblock with triple ticks)

I have no ideas how R2 performance compares with KV. Note that the consistency guarantees are very different. KV is eventually consistent and so auto-caching makes sense. R2 is strongly consistent and will only cache if you set

cache-control

. NOTE: Setting

cache-control

means strong consistency is weakened to eventually consistent. We do have ideas on how to improve R2 to have globally low latency even for cold reads without you needing to think about things. It's going to be a lot of work & I'm not in charge of the product plan so I don't know when we'll prioritize it. I think there's some low hanging fruit to fix this year, but some work is much more difficult. Feedback from our customers to our product manager about what's important to you is the most impactful way to determine when features are built. I also listen here and have some influence from the technical side but making our customers/devs happy is the high order bit. R2 currently has regional affinity although you can't see it/control it/change it. We instantiate the bucket in the physical storage region closest to the request that created the bucket. https://speed.cloudflare.com/ can tell you the server you're going to initiate the request from. If you need explicit region hints let product know why. I can't guarantee we'll implement since our mission is jurisdictional data control, not manual region management.

FWIW my primary mission until roughly the end of the year is to make our customers really happy with performance. So real-world feedback about R2 here will definitely be something I'm paying attention to

I've thought about it and I think the initial version of multi ranges would have to charge a GET request for each range for the time being. It's maybe possible we can bring that price down over time but the primary benefit is that there's an overall latency benefit. You'll have to balance against just doing the requests in parallel on your end as that could sometimes be faster depending on the problem domain.

I suspect is the implicit reason no other providers offer multiple ranges because each GET is an IOP and IOPs are a limited resource for storage products. I can't predict what the future would hold here.

do we know if videos are allowed on r2, looking at previous mentions, it seems unsure

Re your streams question. A purely forwarded stream (i.e. where you're not processing anything and just forwarding), is totally free. We basically stop billing as soon as you return the Response object. https://blog.cloudflare.com/workers-optimization-reduces-your-bill/

I believe so. https://news.ycombinator.com/item?id=20791605

thanks for clarifying

np

(In case anyone is confused, eastdakota is the Cloudflare CEO's HN handle)

oh cool, that first HN post is from my old B2 article 😅

Just wondering if you can give an example of when R2 is not fully consistent? What if a colo looses power/connectivity immediately after a write? How about a write immediately followed by a read in a different colo? Or better yet, give an overview of R2's storage architecture so we can work it out ourselves 😉

I don't think an architecture overview is helpful here but there will be one later on our blog. R2 itself is always strongly consistent - if we return a success the operation is successful and strongly consistent with respect to all other operations that succeeded. Things you build on that may not carry the same guarantee. For example, if you add a cache in front, then different regions can have different versions of the object cached (e.g. long cache duration, read from colo A, write a new version to R2 from colo C, cold read colo B, colos A and B have different objects cached). Another example might be making concurrent requests to read and write into the same object. If you're not doing some kind of synchronization there's no consistency guarantee at your application layer. So while R2 itself will be strongly consistent, that consistency guarantee stops at our API layer and it's the responsibility of the application developer to manage.

What is a cold read? Is it to fetch data from another colo? If so, is it not necessary to query other colos each time to ensure strong consistency?

A cold read means it's not in the cache for the colo you hit. There's no automatic propagation.

You're not going to query other colos. There's no such facility. Generally putting a cache in front of a strongly consistent component removes the strong consistency.

That is independent of how R2 works

Is it correct that R2 has cold reads and non-cold reads? If so, does that mean that there is a dedicated cache for R2 (different from the browser cache or [colo cache](https://developers.cloudflare.com/cache/) )? Also, what happens when I store data in US and try to fetch data from JP, for example?

Is the per request pricing known? Also, will something similar to event notifications exist?

To simplify the problem, imagine R2 being an "origin", everything else basically behaves the same as if you were to use an origin where the data resides.

Obviously the fact it's all internal makes it slightly different, but the easiest way to imagine it is this.

Does this mean that cold read and non-cold read do not apply to R2 itself, but are only relevant when there is a cache layer in the middle?

They do apply, the same way they apply to normal requests...

Thank you for your explanation. I am sorry, I didn't get it well, I will wait for the public beta and detailed announcements about R2 and think about it again.

@itsmatteomanf has it correct. Imagine R2 is an origin. For R2 itself, there's no such thing as a cold or hot read. Once you've decided to hit R2 it's a cold read. Now if you do set a cache-control header in the metadata for the object, that means you've determined you can explain your consistency requirements through that cache policy and thus we will apply it automatically. That automatic caching piece is still WIP so I'm not 100% clear on all the nuances but that's the broad picture.

I understand a little better now. Thank you both for your help.

Follow-up to that: If we use the

Cache-Control

header to cache our R2 objects, would subsequent reads actually be billed as reads, until it expires from the cache?