Quiz: Schema Evolution and Contract Versions

이벤트 스키마에 기본값이 없는 필수 필드를 하나 더했다. 어느 방향이 깨지는가?

• 앞으로 호환이 깨진다 — 옛 읽기 코드가 모르는 필드를 만나 오류를 낸다
• 뒤로 호환이 깨진다 — 새 읽기 코드가 옛 자료에서 그 필드를 찾지 못한다
• 두 방향이 모두 깨진다 — 필드 추가는 어느 쪽에서도 안전하지 않다
• 두 방향이 모두 산다 — 추가는 기본값과 무관하게 언제나 안전하다

필드 이름을 바꾸면서 새 스키마에 별칭(aliases)을 달았다. 결과로 맞는 것은?

• 별칭이 있으면 두 방향이 모두 산다
• 별칭은 쓰는 쪽 스키마에 달아야 뜻이 있다
• 뒤로 호환만 산다 — 별칭은 읽는 쪽 스키마의 것만 쓰이기 때문이다
• 앞으로 호환만 산다 — 옛 이름이 새 자료에 남아 있기 때문이다

금액 필드의 타입을 int 에서 long 으로 넓혔다. 배포 순서로 맞는 것은?

• 쓰는 쪽을 먼저 올린다 — 옛 읽기 코드가 long 을 int 로 자동으로 줄여 읽는다
• 순서가 상관없다 — 숫자 타입 변경은 언제나 양방향으로 안전하다
• 읽는 쪽을 먼저 올린다 — int 는 long 으로 승격되지만 그 반대는 아니다
• 두 쪽을 같은 순간에 올려야 한다 — 숫자 타입은 전환 기간을 둘 수 없다

전환 기간에 여러 판이 섞여 흐르는데 읽는 쪽이 최신 판만 안다. 무엇이 관찰되는가?

• 파이프라인이 즉시 멈추므로 문제를 곧바로 알아챌 수 있다
• 옛 판 줄이 오류 없이 버려져 건수만 조용히 줄어든다
• 옛 판 줄이 최신 판으로 자동 변환되어 아무 일도 생기지 않는다
• 읽는 쪽이 판 번호를 스스로 추론해 옛 판까지 정확히 읽는다

스키마에서 필드를 하나 지우려 한다. 옛 읽기 코드가 안 깨지는 조건은?

• 그 필드가 옛 스키마에서 기본값을 갖고 있었을 때
• 그 필드를 쓰는 다운스트림이 하나도 없을 때
• 지우는 대신 값을 빈 문자열로 채워 계속 내보낼 때
• 그 필드의 타입이 문자열이어서 빈 값으로 읽힐 때

호환 판정을 구현할 때 한 함수로 두 방향을 모두 만드는 방법은?

• 필드 이름 집합의 대칭 차를 구해 양쪽에서 같은 결과를 읽는다
• 스키마 두 개의 해시를 비교해 같으면 두 방향이 모두 산다고 본다
• 판 번호가 큰 쪽을 항상 읽는 쪽으로 두고 한 번만 검사한다
• 읽는 쪽이 쓰는 쪽 자료를 읽는가를 보는 함수에 인자를 뒤집어 두 번 부른다