Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fastly reads from >= two locations #394

Open
RaitoBezarius opened this issue Mar 3, 2024 · 4 comments
Open

Fastly reads from >= two locations #394

RaitoBezarius opened this issue Mar 3, 2024 · 4 comments

Comments

@RaitoBezarius
Copy link
Member

Is your feature request related to a problem? Please describe.

In preparations to experiment other stores of data than our main S3 location, we need to make Fastly read from >= 2 locations.

Describe the solution you'd like

(1) Design a solution using a Fastly personal account, mimicking Fastly configuration of cache.nixos.org
(2) Show smooth fallback between the two locations in case of 404
(3) Suggest a Terraform configuration for this infrastructure

Describe alternatives you've considered

Additional context

@delroth
Copy link
Contributor

delroth commented Mar 3, 2024

(2) Show smooth fallback between the two locations in case of 404

A few more scenarios that I think should be tested:

  • What happens if the primary origin is down / very slow?
  • Depending on how the origin selection is done:
    • If it relies on always trying a primary read first: what's the latency cost for stuff served from the secondary?
    • If it relies on having some kind of dispatch/redirect service with state of what's in the primary origin: what happens if that redirect/dispatch service is down? What happens if the state is wrong?

Depending on the exact specifics of (1) I can imagine there's plenty of new "fun" reliability issues that will crop up in there that will need some consideration.

@RaitoBezarius
Copy link
Member Author

cc @edef1c @flokli we discussed that a long time ago IIRC.

@vcunat
Copy link
Member

vcunat commented Mar 4, 2024

I don't think we can afford for the primary origin to be very slow. Or at the very least not for common-ish *.narinfo paths.

@flokli
Copy link
Contributor

flokli commented Mar 4, 2024

Let's discuss this first for the NAR paths, not NARInfo, which is far less latency-sensitive, and contains more data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants