In all mutations you run through GraphCDN, we wait until the purging is done (as you said, ideally ~150ms). So that means at the point the mutation result comes back to the client, all other queries will get the new content from then on.

You can bypass the cache if you want to, but it's not necessary. As it would just be like a Cache MISS, that would totally work.

I suppose that means writes slow down with the number of dependencies/ dependent caches? How does one estimate the added cost of that write?

Well, that depends on the purging characteristics of Fastly - this blog post is quite nice to read https://www.fastly.com/blog/building-fast-and-reliable-purgi...

We have a limit - you can only "tag" up to 1k items within one query. If you have more items in there, we can't purge all of them.

Due to the nature of the broadcast protocol of Fastlys purging implementation, I assume that it scales quite well - they have really big customers using this for a few years already.

There is a big difference if you're using fastly's cache purging for simple cache invalidation without consistency requirements or if you are trying to do something like you're building.

We're using Fastly ourselves and I was not aware up until today (and in fact I'm taking your word for it, since I can't find it in the docs) that fastly provides consistency guarantees for purges.