Advanced - Entry Key Invalidation

Entry Key Invalidation allows you to forcibly invalidate both waiting keys and entry keys under specific conditions, ensuring visitors must re-queue even if they would normally be protected by Queue Position Retention or Entry Pass. This guide explains the invalidation mechanisms, use cases, and configuration options.

Overview

Entry Key Invalidation is a mechanism that forcibly invalidates keys (both waiting keys and entry keys) to ensure visitors must obtain new keys and re-queue under specific business conditions. This feature works in conjunction with Queue Position Retention and Entry Pass to provide granular control over access patterns.

Why Invalidation is Needed

While Queue Position Retention and Entry Pass provide excellent user experience by protecting visitors from losing their position, there are business scenarios where you need to enforce re-queuing:

• Fair access control: Ensure all visitors re-queue for critical phases
• Load management: Control server load by invalidating passes at specific times
• URL-based restrictions: Prevent pass sharing across different service endpoints
• Event phase transitions: Enforce re-queuing when moving to different event phases

What Gets Invalidated

Entry Key Invalidation affects two types of keys:

1. Waiting Keys (used for queue positions):

• When invalidated: Queue Position Retention is bypassed
• Effect: Visitors lose their queue position and must start from the end of the queue, regardless of Queue Position Retention period
• Use case: Enforce fair re-queuing even when Queue Position Retention is enabled

2. Entry Keys (used for service entry):

• When invalidated: Entry Pass is bypassed
• Effect: Visitors must re-queue through the waiting room, regardless of Entry Pass validity period
• Use case: Force re-queuing for critical service phases or specific URLs

How It Works

Entry Key Invalidation operates on a simple principle: force key reissuance when invalidation conditions are met. This ensures visitors cannot rely on previously issued keys and must go through the waiting room again.

Technical Principle

Any key (waiting key or entry key) that meets the invalidation conditions will be forcibly invalidated, causing the system to issue a new key, regardless of Queue Position Retention periods or Entry Pass validity periods. This means:

• Waiting key invalidation: Even with Queue Position Retention enabled and regardless of the Queue Position Retention period, visitors who disconnect and reconnect will lose their previous queue position and start from the end
• Entry key invalidation: Even with Entry Pass enabled and within Entry Pass validity period, visitors must re-queue if invalidation conditions are met, regardless of the Entry Pass validity period

Entry Key Invalidation provides two types of invalidation conditions:

1. URL-Based Invalidation

Invalidate keys when visitors access specific URLs.

Use case example: Multi-page event with selective access control

Let's say you have a segmented event where:

• Trigger rule: /event/1, /event/2, /event/3 paths trigger waiting room
• Entry Pass: 1 hour validity period
• Business requirement: All event pages except /event/3 allow Entry Pass, but /event/3 should always require re-queuing

Scenario Timeline:

10:00 AM  Visitor enters /event/1, receives entry key
          → Entry Pass valid for 1 hour until 11:00 AM
          
10:15 AM  Visitor accesses /event/2
          → Entry Pass still valid
          → Direct entry without queue ✓
          
10:30 AM  Visitor accesses /event/3
          → URL-based invalidation triggered
          → Entry key invalidated
          → Must go through waiting room again ✗
          
10:31 AM  Visitor receives new entry key after waiting
          → Access granted to /event/3 ✓

Configuration:

Simply enter the full URL path (including protocol) of the service path you want to invalidate:

https://example.com/event/3

Technical details:

• Works with UTI (URL-Triggered Integration) environments
• Full path matching required (protocol + domain + path)
• Only one URL can be configured per segment
• Available only in Basic Control segments (not supported in Section Control segments)

2. Timer-Based Invalidation

Automatically invalidate all keys issued before a specific point in time.

Use case example: Event fairness during critical phases

Let's say you have an event where:

• Entry Pass: 1 hour validity period by default
• Multiple event pages (/event/1, /event/2, /event/3) allow free navigation within 1 hour
• Critical requirement: After 2:00 PM, all visitors must re-queue for event fairness

Scenario Timeline:

1:00 PM   Visitor enters /event/1, receives entry key
          → Entry Pass valid until 2:00 PM
          
1:30 PM   Visitor navigates to /event/2
          → Entry Pass still valid
          → Direct entry ✓
          
1:45 PM   Visitor navigates to /event/3
          → Entry Pass still valid
          → Direct entry ✓
          
2:00 PM   Timer-based invalidation triggers
          → All entry keys become invalid
          
2:05 PM   Visitor tries to access any event page
          → Entry key invalidated at 2:00 PM
          → Must go through waiting room again ✗

Configuration:

Set a specific time when invalidation should take effect (minimum: 1 minute resolution):

Invalidation Time: 2:00 PM

How it works:

• System checks when each key was issued against the configured invalidation time
• Keys issued before the invalidation time become void (regardless of Queue Position Retention/Entry Pass validity periods)
• Keys issued after the invalidation time have normal behavior
• This ensures all keys issued before a critical event time must be re-queued

Combined Invalidation

URL-based and Timer-based invalidation can be used together for complex access control scenarios:

Example: Event with both URL and time restrictions

Configuration:
- URL invalidation: https://example.com/event/critical-phase
- Timer invalidation: 2:00 PM

Behavior:
- Before 2:00 PM: Only /event/critical-phase requires re-queuing
- After 2:00 PM: All pages require re-queuing

Configuration

Default Behavior

URL-based and Timer-based invalidation are independent settings that can be enabled or disabled separately:

• URL-based invalidation OFF (default): No URL-based invalidation occurs
• Timer-based invalidation OFF (default): No timer-based invalidation occurs
• Both features can be enabled independently
• Keys remain valid according to their respective Entry Pass validity periods when invalidation is disabled

When enabled:

• Invalidation checks occur at each access attempt
• Keys that meet the enabled invalidation conditions are immediately invalidated
• New keys must be obtained through the waiting room

Configuration Steps

You can configure Entry Key Invalidation when creating or editing a Basic Control Segment:

1. Navigate to your segment's settings (creation or edit mode)
2. Go to Advanced Settings section
3. Enable invalidation methods (can enable both independently):
   • Enable/disable URL-based invalidation
   • Enable/disable Timer-based invalidation
4. Configure invalidation conditions:
   • URL-based: Add full URL when enabled
   • Timer-based: Set invalidation time (minimum: 1 minute resolution) when enabled
5. Save Configuration: Apply your settings

Segment Type Support

Basic Control segments:

• Both URL-based and Timer-based invalidation are available

Section Control segments:

• Only Timer-based invalidation is available
• URL-based invalidation is not supported (no UTI/Trigger rule support)

Best Practices

When to Use URL-Based Invalidation

Use URL-based invalidation when:

• Different pages require different access levels
• Some pages are more critical and require fresh queuing
• You want to prevent users from accessing certain pages even with Entry Pass
• Multi-page events with selective access control

Example scenarios:

• Live streaming events: Main page allows Entry Pass, Q&A page requires re-queuing
• Multi-phase sales: Browse allows Entry Pass, purchase page requires re-queuing
• Tiered access: Free content allows Entry Pass, premium content requires re-queuing

When to Use Timer-Based Invalidation

Use timer-based invalidation when:

• Fairness is critical at specific event times
• You need to control server load at scheduled intervals
• Event phases transition at fixed times
• You want to enforce periodic re-verification

Example scenarios:

• Live events: Force re-queuing at showtime
• Limited releases: Invalidate passes after initial rush period
• Scheduled sales: Require fresh queuing for each sale phase
• Event transitions: Move from warmup to main event with re-queuing

Combining Both Methods

Complex event scenarios benefit from combined invalidation:

Event Structure:
- Warmup phase (10:00 AM - 11:00 AM): URL-based invalidation for premium content
- Main event (11:00 AM - 12:00 PM): Timer-based invalidation at 11:00 AM
- Q&A phase (12:00 PM - 1:00 PM): URL-based invalidation for Q&A URLs

Configuration:
- URL invalidation: 
  * https://example.com/event/premium
  * https://example.com/event/qa
- Timer invalidation: 11:00 AM

Precautions

Consider user experience:

• Too frequent invalidation can frustrate users
• Communicate invalidation timing to users when possible
• Balance fairness with usability

Monitor system load:

• Sudden influx of re-queuing users can create spikes
• Plan invalidation timing to avoid overload
• Consider traffic patterns before setting invalidation times

Test thoroughly:

• Verify invalidation triggers work as expected
• Test with Queue Position Retention and Entry Pass combinations
• Ensure users understand they need to re-queue

Interactions with Other Features

Queue Position Retention Interaction

When Queue Position Retention is enabled and Entry Key Invalidation is triggered:

• Waiting key is invalidated: User loses queue position, must start from end
• Queue Position Retention period is bypassed: Even if within Queue Position Retention period, key invalidation takes priority
• New key issued: User receives fresh waiting key and joins queue from back

Priority: Invalidation > Queue Position Retention

Entry Pass Interaction

When Entry Pass is enabled and Entry Key Invalidation is triggered:

• Entry key is invalidated: User loses Entry Pass privileges
• Entry Pass validity period is bypassed: Even if within Entry Pass validity period, invalidation takes priority
• Re-queue required: User must go through waiting room again

Priority: Invalidation > Entry Pass

Combined Protection Scenarios

Scenario 1: URL invalidation during Entry Pass window

Entry Pass: 1 hour validity
URL invalidation: /critical-page
Timeline:
  10:00 AM → Entry Pass granted
  10:30 AM → Access /normal-page (Entry Pass valid)
  10:45 AM → Access /critical-page (URL invalidation triggers, re-queue required)

Scenario 2: Timer invalidation during Queue Position Retention period

Queue Position Retention period: 5 minutes
Timer invalidation: 10:28 AM
Timeline:
  10:25 AM → User disconnects (queue position #50 retained by Queue Position Retention)
  10:28 AM → Timer invalidation triggers (waiting key invalidated)
  10:29 AM → User reconnects (timer already triggered)
              → Must re-queue from end

Verification

You can verify Entry Key Invalidation functionality with a simple test:

Setup:

1. Enable Entry Pass with 30-minute validity period
2. Enable Entry Key Invalidation (URL or Timer based)
3. Configure invalidation condition

Test steps:

10:00 AM  Visitor enters service, receives entry key
          → Entry Pass valid until 10:30 AM
          
10:15 AM  Visitor accesses service
          → Entry Pass still valid
          → Direct entry ✓
          
10:20 AM  Invalidation condition met (URL accessed or timer triggered)
          → Entry key invalidated
          
10:25 AM  Visitor attempts service access
          → Entry key invalidated
          → Must go through waiting room again ✗
          → Re-queues, receives new entry key
          
10:26 AM  Visitor accesses service with new key
          → Direct entry ✓ (new Entry Pass issued)

What this proves:

• Invalidation takes priority over Entry Pass validity period
• Invalidated keys cannot be reused
• Users must obtain new keys through waiting room
• New Entry Pass is issued after successful re-queue

FAQ

Can I use invalidation without Queue Position Retention or Entry Pass?

Yes, invalidation is independent. However, invalidation has maximum impact when used with Queue Position Retention and Entry Pass, as it provides granular control over when to bypass these protections.

What happens if I trigger invalidation multiple times?

Invalidation is event-based: each time a key is checked and meets invalidation conditions, it gets invalidated. You can combine multiple invalidation conditions (URL + Timer) for complex scenarios.

Can I disable invalidation after enabling it?

Yes! Disabling Entry Key Invalidation is a real-time change that takes effect immediately. Keys that were invalidated remain invalid, but new keys issued after disabling invalidation will have normal behavior.

Does invalidation work with all integration types?

URL-based invalidation works with UTI (URL-Triggered Integration). Timer-based invalidation works with all integration types (UTI and CBI).

Can I invalidate waiting keys and entry keys separately?

No. Entry Key Invalidation invalidates both waiting keys (used for queue positions) and entry keys (used for service entry) simultaneously when invalidation conditions are met. There is no separate configuration to invalidate only waiting keys or only entry keys. When you enable Entry Key Invalidation, both types of keys are invalidated together.

For related configuration options, see Advanced Timing, Queue Position Retention, and Entry Pass documentation.