architecture · Oct 2023 – Sep 2024

Integrating 3 GDS Platforms and 35+ Airline APIs

Integrated 3 GDS systems via SOAP (+13% revenue) and built and optimized 35+ REST, GraphQL, and SOAP airline APIs with validation and structured errors (+8% backend performance).

Role: Built the GDS integrations, the airline-facing APIs, and the CI/CD pipelines that ship them
Team: Backend integrations team
Scope: Airline integrations across 3 global distribution systems (GDS) at Universal Weather and Aviation
Level: SDE-1

Revenue

baseline+13%

Method: Revenue increase attributed to integrating 3 GDS systems via SOAP APIs and the AI-driven microservices built on them.
Window: during tenure

Backend performance

baseline+8%

Method: Backend performance improvement from building and optimizing the airline-integration APIs with input validation and structured error handling.
Window: during tenure

APIs built & optimized

35+

Method: Count of REST, GraphQL, and SOAP APIs built and optimized for airline integrations.
Window: Oct 2023 – Sep 2024

Context

At Universal Weather and Aviation I worked on the integrations that connect airline operations to the outside world — in particular, global distribution systems (GDS), the external platforms airlines use for distribution. Each one has its own SOAP interface, schemas, and quirks. I integrated three of them and built and optimized 35+ REST, GraphQL, and SOAP APIs for airline integrations.

One internal model, many partners

The fastest way to integrate a partner is to call its API straight from the feature that needs it. Do that for three partners and every feature has to understand three sets of quirks.

So each GDS sits behind its own adapter that translates its SOAP interface into one shared internal model. Partner-specific complexity lives in exactly one place per partner; features — including the AI-driven microservices built on this data — are written once. That integration work is what drove the 13% revenue increase.

Fail fast, fail clearly

With high request volumes against external systems, bad input that travels deep into the stack is expensive: it burns partner calls and compute, then fails with an error nobody can act on. Across the APIs I added strict validation at the boundary and a structured error model, so bad requests fail cheaply with a clear message. That was part of an 8% backend performance improvement.

Shipping it reliably

Dozens of APIs and several services meant deployments needed to be boring. I automated CI/CD with Terraform, Docker, and Kubernetes so every environment is reproducible from code and every release goes through the same pipeline.

What broke

One GDS reported some business failures inside a successful SOAP response instead of as a SOAP fault. The first version of its adapter only checked for faults, so those requests looked like successes until downstream checks caught the mismatch. Since then I treat a partner's error semantics as part of its contract and test adapters against recorded real responses — every failure shape the partner actually sends, not just the schema.

Outcomes

Three GDS systems integrated behind one internal model, 35+ airline-integration APIs built and optimized, +13% revenue, +8% backend performance, and automated pipelines that made shipping integration services routine.

Decision Records

DR-001 · architecture

Normalizing each GDS's SOAP interface behind an adapter — so the rest of the system speaks one internal model — is what let us integrate three external systems without three copies of every feature

Context

Each GDS exposes its own SOAP interface with its own schemas, quirks, and fault semantics. The airline-facing services on top needed one consistent view of the data, regardless of which GDS it came from.

Options considered

✗
Call each GDS's SOAP API directly from the features that need it
Every feature learns every partner's quirks. Adding a GDS or handling a partner change touches the whole codebase.
✓
One adapter per GDS that translates to a shared internal model
Partner-specific complexity lives in one place per partner. Features are written once against the internal model, and a new GDS is a new adapter.

Tradeoffs

The internal model has to be general enough for all three partners, and the translation layer is code to maintain. Much cheaper than partner logic leaking everywhere.

Outcome

Three GDS systems integrated behind one internal model that the airline-facing services and AI-driven microservices build on.

DR-002 · architecture

Strict input validation and a structured error model across the 35+ APIs made failures cheap — and improved backend performance by rejecting bad requests before they did expensive work

Context

Airline integrations exchange high volumes of requests with external systems. Malformed input that reached deep into the stack wasted downstream calls and produced vague errors that were slow to debug on both sides.

Options considered

✗
Pass requests through and let downstream systems fail
Bad input consumes partner calls and compute before failing, and clients get errors they can't act on.
✓
Validate every request at the API boundary; map failures to structured, consistent errors
Bad requests fail fast and cheaply with an actionable message. Consistent error shapes make integrations easier for clients and support.

Tradeoffs

Validation rules have to be kept in step with partner and client schemas. Worth it for faster, clearer failures.

Outcome

Across the 35+ REST, GraphQL, and SOAP APIs, bad input fails fast with structured errors — part of an 8% backend performance improvement.

DR-003 · architecture

Infrastructure as code and automated CI/CD pipelines made deployments repeatable — which matters when many integration services ship often

Context

With dozens of APIs and several integration services, manual or semi-manual deployments were a source of drift and risk.

Options considered

✗
Keep deployments partly manual
Environments drift, releases depend on who is doing them, and scaling up means more manual work.
✓
Terraform for infrastructure, Docker images, Kubernetes deployments, automated pipelines
Every environment is reproducible from code, and releases go through the same pipeline every time.

Tradeoffs

Up-front investment in pipeline and infrastructure code. Paid back in deployment scalability and reliability.

Outcome

Automated CI/CD pipelines improved deployment scalability and reliability.

Where I Got It Wrong

Failure 1

One GDS reported certain business failures inside a successful SOAP response body rather than as a SOAP fault, and the first version of its adapter treated those responses as success

Cost: Requests that had actually failed looked successful until downstream checks flagged the mismatch, and the adapter's response handling had to be reworked

Lesson: A partner's error semantics are part of its contract. Test adapters against recorded real responses — including every failure shape the partner actually sends — not just against the schema

Long-Term Impact

An adapter-based integration layer and automated delivery pipeline that made adding partners and shipping integration services routine rather than risky.