---
title: "Travel PII ve Passenger Data Boundaries"
description: "Passenger PII, identity, contact, payment ve travel document verisini search, booking, logging ve provider entegrasyonlarında güvenli sınırlarla modelleyin."
slug: "travel-pii-passenger-data-boundaries"
translationKey: "architecture-travel-pii-passenger-data-boundaries"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["pii","passenger","privacy","security","booking","travel"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

Travel booking sistemleri search aşamasında anonim çalışabilirken booking ve servicing sırasında passenger identity, contact ve document verisi işlemek zorunda kalabilir. Temel prensip **PII'yi domain boyunca taşımak yerine ihtiyaç olan boundary'de açmak** olmalıdır.

## Data boundary

```mermaid
%% title: Passenger data boundary
%% description: Search ve offer katmanları PII-free kalırken booking boundary tokenized passenger data ile provider adapter'a erişir.
flowchart LR
  A[Search / Offer Domain] --> B[Booking Intent]
  C[Passenger Vault] --> D[Scoped Passenger Reference]
  B --> E[Booking Orchestrator]
  D --> E
  E --> F[Provider Adapter]
  F --> G[Travel Provider]
  E --> H[Redacted Events / Logs]
```

## Data classes

Ayrı sınıflandırın:
- traveler/passenger name,
- email/phone,
- date of birth,
- nationality,
- passport/identity document,
- loyalty number,
- special service requests,
- payment identifiers,
- booking references.

Hepsi aynı retention ve access policy'ye sahip olmak zorunda değildir.

## Token/reference pattern

Search, analytics ve observability katmanına raw passenger record taşımak yerine internal reference kullanın:

```text
passengerProfileRef -> secure vault lookup -> scoped provider payload
```

## Least privilege

Provider adapter yalnız ilgili booking operation için gerekli alanlara erişebilmelidir. Search/ranking service passport veya phone görmemelidir.

## Logging

Yasaklanması gereken örnekler:
- full provider request body,
- passport number,
- full email/phone,
- raw payment details,
- auth headers/tokens.

Loglarda booking ID/provider reference gibi operational ID'ler tercih edilmelidir.

## Encryption and secrets

PII at-rest ve in-transit protection, secret management ve key rotation altyapının temel parçasıdır. Provider credential ile passenger data aynı config/log surface'inde tutulmamalıdır.

## Retention

Retention operation bazlı olmalıdır:
- booking lifecycle ihtiyacı,
- servicing/refund period,
- legal/accounting obligation,
- fraud/dispute handling,
- explicit deletion/anonymization policy.

"Belki lazım olur" retention gerekçesi olmamalıdır.

## Analytics boundary

Analytics event'lerinde raw PII yerine:
- market,
- route/destination class,
- booking state,
- provider,
- amount bucket,
- latency
gibi business fields kullanılmalıdır.

## Support / ops access

Ops ekranları maskelenmiş data göstermeli; sensitive field reveal explicit permission ve audit trail gerektirmelidir.

## Failure modes

- PII'nin trace/log'a düşmesi,
- test fixture içinde gerçek passenger data,
- analytics pipeline'a email gönderilmesi,
- cache key'de passport/email,
- provider error body'nin kontrolsüz persist edilmesi,
- backup retention'ın primary DB policy'den uzun olması.

## Observability

Privacy/security metrics:
- redaction failure count,
- unauthorized reveal attempt,
- sensitive-field access audit,
- retention deletion failures,
- raw payload persistence detection.

## Production checklist

- data classification,
- PII-free search domain,
- secure passenger reference,
- scoped adapter access,
- redaction,
- retention policy,
- masked ops UI,
- audited reveal,
- sanitized fixtures,
- backup/deletion parity.