Near-real-time reservation data, and proving the fast path was actually fast.

01Context

Two things were true at once. Brands needed near-real-time booking visibility, which the batch reporting model couldn't give them. And booking API latency mattered to contact-center response times, which are contractual. The engineering answer was a streaming reservation data product on AWS (Kinesis for ingestion, Glue for transformation, Athena for query) and a DynamoDB Accelerator (DAX) deployment to cut read latency on the booking path. Both needed someone to prove, with data, that they did what they claimed.

02My role

I supported delivery of the data product from the requirements and validation side: defining what brands needed to see, mapping reservation fields from source to the queryable layer, and writing the Athena and SQL queries that verified the stream was complete and correct. On the DAX rollout I contributed to performance validation, defining the test scenarios, comparing latency before and after against the SLA targets, and documenting the results for sign-off.

03Approach

• Map before you stream. A field-level mapping from reservation source to the Athena schema was the reference for every validation query and every "why doesn't this number match" conversation.
• Validate completeness, not just presence. Athena queries reconciled event counts and key totals against the source system by time window, so a silently dropped partition surfaced as a number, not a complaint.
• Test the cache like a client. DAX validation scenarios mirrored real booking-path calls (lookups, availability reads, repeat reads), measured p50/p95 latency before and after, and compared them to the SLA thresholds brands actually hold HotelKey to.
• Write it down for sign-off. Results went into a validation record with the scenarios, the numbers, and the pass/fail against SLA, which is what let the rollout proceed with confidence rather than optimism.

04Outcome

The data product gave brands the live view they'd asked for, and the validation layer meant that when a number looked wrong, there was a query that said why within minutes. The DAX validation record is what turned "faster" into an evidence-backed claim.

05What I'd do differently

Package the validation queries as a scheduled job with alerting from the start, rather than running them on demand. Reconciliation that only happens when someone remembers is reconciliation that eventually stops happening. The pattern, mapping spec in, validation SQL out, is what the Data Mapper project generalizes.