← all entries
A-TIER resource

Booking.com AI observability — Kafka buffer and PII redaction before Arize

therobertta · 2026-08-28T17:11:05.000Z · in AI Saves, Vol. 8
Open post ↗

100k ft — What is this?

Booking.com AI observability — Kafka buffer and PII redaction before Arize
resourceA-tier

50k ft — Why care?

Walkthrough of Booking.com's GenAI telemetry architecture: apps emit traces to a collector, which normalizes them onto a managed Kafka bus (durable buffer decoupling producers and consumers), through a dedicated PII-redaction service that masks span attributes and text, then out to Arize for real-time monitoring and a warehouse for offline analytics and backfills. A second pipeline ships ML prediction logs to Arize for ranking and fraud models.
architecturedata sciencesecuritysoftware development

10k ft — Key takeaways

• Dual-export to a monitoring tool and a warehouse for long-term trends. • Make PII redaction a service in the pipeline, not a policy. • Put a durable message bus between AI apps and observability vendors.

5k ft — Tools & techniques

Arize, Kafka LLM tracing, PII redaction, fine-tuning, message-bus decoupling

1k ft — Deep-dive / try it

Most teams buy an observability tool and call it an architecture. The interesting part of this diagram isn't the vendor at the end, it's everything before it: a durable buffer so producers and consumers can fail independently, and PII redaction as its own service rather than a policy someone is supposed to follow. Compliance built into the pipeline is the difference between an AI system that runs in production and a demo legal shuts down. None of the hard parts here are AI parts.
Transcript excerpt
This is how booking.com scales AI observability with Arise to those that are interested in enterprise architectures and responsible for figuring out what is a scalable architecture to meet our AI adoption and AI native development needs going forward as a technology team. I found this to be a very interesting use case. This is a really interesting diagram to kind of ground on in terms of their architecture. So on the left you have N number of gen AI applications. They're using an AI telemetry collector. They pull that in, they normalize it, and then they have traces going into a secure message bus. In this case, it looks like they are using a managed Kafka service, so that's a durable buffer that absorbs spikes and decouples producers from consumers, and then they have a PII redaction service. I thought this was really interesting for anybody in enterprise software that has to deal with compliance and regulation and privacy and things like that. So they specifically call that out in their architecture that they have a service that detects and masks PII and span attributes and text fields. And then they go and export to Arise and a warehouse. Redacted traces are sent to Arise in real time and stored in the warehouse for analytics. Arise will then enrich with space, project metadata, etc. And then on the warehouse ingestion side, it looks like these persist to use for offline analytics, long term trends and backfills. And here's another diagram for their ML prediction log…

Appears in

More from @therobertta

Collection: AI Saves, Vol. 8