BACK TO CONNECTORS

Queue-it's Fastly Connector v5 uses a Compute@Edge service to integrate a Fastly protected WebServer with Queue-it.

This page is intended to give a high-level technical overview of the Fastly Connector v5. To prevent malicious actors from compromising the security of our customer's high-profile sales and registrations, we host our in-depth documentation for Connector v4 and up, in private repositories.

If you need more detailed integration documentation than this page offers, contact one of our technical experts who can guide you on the optimal setup for your tech stack.

• Request received
  • User request reaches the Queue-it Connector on your edge infrastructure.
• Connector evaluation
  • The Queue-it Connector checks:
    • Does the request target a protected path?
    • Does the visitor have a valid Queue-it token?
• Call to Queue-it for decision logic
  • If the request is protected and no valid token is present, the Connector calls Queue-it to determine if the visitor needs to be queued based on your Queue-it configuration (e.g. traffic levels are above your threshold, rules allowing certain users to bypass the queue, waiting room is active or idle, etc.)
• Redirect to Queue-it
  • If the visitor needs to be queued, they are redirected with an HTTP 302 to a waiting room on Queue-it’s infrastructure.
  • If the visitor does not need to be queued (e.g. in a 24/7 Protection setup with low inflow), they proceed directly to the protected page without the need for a 302 redirect.
• Access granted
  • When it’s their turn, they are redirected back to your site with another HTTP 302 and given a signed token. With the signed token, the visitor’s request proceeds to the protected part of your site, and they continue their user journey without queuing.

In Bring Your Own CDN (BYO CDN) deployments, Queue-it operates behind your CloudFront CDN, allowing traffic to continue flowing through your existing CDN infrastructure, security controls, monitoring tools, and routing policies while benefiting from Queue-it's traffic orchestration capabilities.

You can read more about the Connector flow for versions 5 and up on our blog, including user flow diagrams for when users pass without queuing and in cases of service disruptions.

To learn more about how Queue-it works, including waiting room types and when/where Queue-it protects your site, visit Queue-it for developers.

To integrate using the Queue-it Fastly Connector v5, you will need:

• An active Queue-it account
• An active Fastly account
• Queue-it admin available (Someone available with GO Queue-it Platform access and familiarity with GO account configuration settings.)
• AWS admin available (Someone available with access to the customer AWS account and familiarity with all existing CloudFront environmental configurations (Lambda functions))
• Fastly V5 Connector Download Access (CloudFront admin must have been provisioned with access to secure Queue-it V5 Connector Github repository – not available for public access.)
• A non-production Fastly environment that can be used for implementing and testing the new Queue-it connector.

Note that BYO CDN integrations require Queue-it’s White Label add-on and are only available on enterprise plans.

Complete these steps in order for best results.

1. Create a Compute service
2. Add a new domain and relevant hosts
3. Create a Config store and link it to the relevant services

Waiting rooms and their protection scope are created and configured in the GO Queue-it Platform and any server-side (KnownUser) configuration information must be propagated to the CloudFront environment for real-time access by the Queue-it Connector. When an integration configuration is saved (published) in the GO Queue-it Platform, the server-side configuration settings are packaged into a server-side JSON file and positioned on the Queue-it server, ready for secure downloading. Propagation of these settings (JSON) to the CloudFront environment is performed automatically when the Queue-it integration configuration is published.

Queue-it's actions and triggers framework gives you a high degree of flexibility in determining what aspects of your site are covered by the virtual waiting room (see How Queue-it Works).

This allows you to tailor protection to the specific business-critical experiences that matter most during periods of high demand.