Workflow Simulator for Testing Flight Integration Connectors

agoda · E-commerce · 2026 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Flight supplier connector testing and future AI-assisted scenario generation

Agoda needed faster, earlier validation of flight supplier connectors without requiring engineers to spin up a full production-like booking stack for every integration test.

Constraints:

Supplier connectors translate search, pricing, ancillaries, booking, cancellation, and other flight operations.
Traditional E2E tests required frontend services, messaging systems, caches, microservices, and background workers.
Late E2E failures increased remediation cost and forced reruns of whole test suites.
Supplier-specific tests had limited reuse across connectors.
The current system is DAG-based simulation; AI-assisted scenario generation is a future direction, not implemented production behavior.

Architecture

Agoda built a Workflow Simulator around four main components: a Scenario Builder that creates realistic booking contexts, a DAG-based Workflow Executor that simulates upstream booking steps and calls connectors through internal contracts, assertion layers that validate endpoint and cross-workflow behavior, and a Test Runner that lets engineers execute connector tests locally before full E2E validation.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  scenario-builder["Scenario Builder"] --> workflow-executor["Workflow Executor"]
  future-ai-scenario-generator["Future AI scenario generator"] --> scenario-builder
  workflow-executor --> connector-under-test["Connector under test"]
  connector-under-test --> supplier-test-environment["Supplier test environment"]
  workflow-executor --> assertions["Assertions"]
  assertions --> test-runner["Test Runner"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Scenario Builder`	Defines target acceptance scenarios and creates scenario context such as passenger composition, itinerary, cabin class, and ancillaries.	`Workflow Executor`
`Workflow Executor`	Traverses a DAG of simulated business steps and orchestrates connector calls.	`Scenario Builder`, `Connector under test`, `Assertions`
`Connector under test`	Supplier connector being validated through Agoda's internal contracts.	`Workflow Executor`, `Supplier test environment`
`Supplier test environment`	External supplier-side environment used by the connector during simulation.	`Connector under test`
`Assertions`	Validate endpoint contracts, field rules, logical consistency, and cross-step scenario correctness.	`Workflow Executor`, `Test Runner`
`Test Runner`	Initializes the simulator and executes connector tests locally or early in implementation.	`Assertions`
`Future AI scenario generator`	Proposed future component for generating scenarios and edge cases to improve coverage.	`Scenario Builder`

Data flow

A test scenario defines passenger, itinerary, cabin, and ancillary context; the workflow executor traverses a DAG of simulated booking steps; each node calls the connector and records requests/responses while preserving shared state; endpoint and workflow assertions validate the recorded interactions; and full E2E testing remains the final integration check.

3 supporting quotes

“The Workflow Simulator consists of four main components that work together to simulate, execute, and validate connector behavior:”summary, stated

“The workflow is modeled as a directed acyclic graph (DAG) representing simulated business steps.”summary, implied

“It records each request and response while maintaining shared state, carrying forward required information from one step to the next.”summary, stated

Why this architecture

The simulator deliberately trades production-like scalability for local clarity and traceability, because the goal is early connector validation rather than full-stack load or availability testing.

“The simulator is designed specifically for connector testing and prioritizes simplicity and clarity of execution over scalability and availability.”summary, stated

“Unlike production systems that rely on caching and asynchronous communication to achieve scale, the simulator intentionally omits these optimizations.”summary, stated

Models used: Directed acyclic graph workflow simulation · Future AI-assisted scenario generation

Scale

Agoda integrates with numerous external partners including airlines, OTAs, and providers.
“Agoda operates a flight booking platform that integrates with numerous external partners including airlines, OTAs (Online Travel Agencies), and various providers.”summary, stated
The connector layer spans search, pricing, ancillaries, booking, and post-booking flows.
“The connector is business-critical as it facilitates translation across all business operations including search, pricing, ancillaries, booking, and post-booking flows like cancellations.”summary, stated

Alternatives considered (roads not taken)

Run full production-like E2E stacks for connector testing

Rejected because: They were slow, expensive, blocked by unrelated dependencies, and found bugs late.

“Testing required spinning up a full production-like stack that mirrored the production architecture, including frontend services, asynchronous messaging systems, caching layers, multiple microservices, and background workers.”summary, stated

Replace E2E testing completely

Rejected because: The simulator does not cover production-only architecture, race conditions, rate limits, or final integration behavior.

“The article clearly acknowledges that this approach is not a replacement for full end-to-end testing.”summary, stated

Keep all scenario generation manual

Rejected because: Agoda identifies AI-assisted edge-case generation as a future way to improve coverage and quality.

“The "What's next?" section states that Agoda will "explore AI-assisted techniques to help generate scenarios and edge cases, improving test coverage and quality."”summary, stated

Patterns

`eval-driven-development` (testing)

The Workflow Simulator shifts connector quality checks earlier so engineers can validate behavior locally before full E2E tests.

“This enables shift-left testing, as engineers can run realistic flows early in implementation, catching issues sooner and reducing the risk of late-cycle defects and downstream surprises.”summary, stated

`structured-output-contract` (integration)

Endpoint assertions validate contract fields, types, formats, lengths, and logical consistency across connector requests and responses.

“Endpoint assertions validate individual connector endpoint requests and responses, including contract validation, required fields, field types, formats, length constraints, and logical consistency across fields.”summary, stated

`synthetic-data-generation` (future direction)

The current simulator may later use AI to generate diverse realistic scenarios and edge cases for broader coverage.

“This future direction represents a potential LLMOps use case where language models could be employed to automatically generate diverse test scenarios based on business requirements,”summary, stated

Tradeoffs

Optimize simulator clarity over production scalability

Chose Synchronous calls and recorded interactions over Caching, asynchronous messaging, and production-scale architecture inside the simulator.

Rationale: Connector engineers needed traceable local feedback more than production-like throughput in this layer.

“Instead, it performs synchronous calls and records all interactions in a straightforward and transparent manner, making execution easier to trace and failures easier to diagnose.”summary, stated

Use supplier-agnostic internal contracts

Chose Reusable connector-facing simulator interactions over Supplier-specific test harnesses for every integration.

Rationale: The same simulator can validate multiple suppliers and new connectors with minimal additional work.

“Because the simulator communicates through the connector's internal contract, it is supplier-agnostic and reusable across multiple suppliers and connectors with minimal additional work.”summary, stated

Gotchas (what bit them)

Full-stack connector tests found defects late.

Root cause: Traditional testing required connector implementation, supplier test environments, and a complete production-like stack before execution.

Resolution: Use a simulator to validate connector logic early through realistic local workflows.

“Defects were discovered late in the delivery cycle when remediation costs were significantly higher. When bugs were found during E2E testing, the entire test suite typically needed to be rerun after fixes were applied, further increasing effort and slowing delivery.”summary, stated

E2E tests were vulnerable to unrelated system instability.

Root cause: Production-like testing depended on upstream and downstream services beyond the connector under test.

Resolution: Simulate surrounding ecosystem behavior and call connectors through reusable internal contracts.

“E2E tests could be blocked by issues in unrelated dependencies such as platform problems or unstable upstream or downstream services, creating bottlenecks in supplier integrations.”summary, stated

The simulator cannot reproduce all production failures.

Root cause: It intentionally omits asynchronous communication, caching, parallelism, rate limits, and some production-only constraints.

Resolution: Keep full E2E tests as final validation rather than treating the simulator as a replacement.

“Some complex failures may not be applicable to the workflow simulator. For example, race conditions and production-only constraints such as rate limiting cannot be reproduced without a full staging environment.”summary, stated

Evaluation

Agoda evaluates connector correctness with endpoint assertions and workflow-scenario assertions over recorded request-response pairs and accumulated scenario state.

Metrics: Endpoint contract validation · Field type/format/length validation · Cross-step data propagation · Workflow-scenario consistency · Supplier-side booking detail comparison

“Assertions: The simulator supports two types of assertions. Endpoint assertions validate individual connector endpoint requests and responses, including contract validation, required fields, field types, formats, length constraints, and logical consistency across fields.”summary, implied

“Workflow-Scenario assertions validate end-to-end consistency across multiple connector endpoints using the defined scenario context and recorded request-response logs.”summary, stated

Outcomes

Engineers can run realistic supplier connector flows locally without the full E2E stack.
The simulator shortens feedback loops and catches issues earlier in connector implementation.
AI-assisted scenario generation remains a future direction rather than current production behavior.

The simulator targets a connector layer spanning many external flight suppliers and multiple booking business operations.

“The Workflow Simulator enables fast local testing by allowing engineers to run realistic flows on their machines without spinning up the entire E2E stack.”summary, stated

“The planned AI integration appears to be a considered enhancement rather than a wholesale replacement of proven testing methodology, which suggests a pragmatic approach to adopting LLM capabilities”summary, stated