클라이언트, 서버 두 DB의 데이터를 동시에 수정할 때 무결성 보장

기종이 다른 두 가지 데이터베이스를 동기화 시키는 작업은 아주 어려운 과제입니다. 만들고 계신 어플리케이션이 어떤 일을 하는지 모르겠지만, 어플리케이션 전체를 개발하는 것 보다 이 작업이 더 어려울수도 있습니다. 우선 데이터베이스 두 개를 싱크하는 작업이 꼭 필요한지를 먼저 생각하셔야 합니다. 서버가 MSA 구조여서 서로 데이터를 싱크하는 경우는 많이 봤지만, 클라이언트도 각자의 DB를 가지고 있어 중앙 서버와 싱크해야 하는 경우는 드뭅니다. 보통 클라이언트단의 데이터베이스는 서버의 데이터베이스와 지위가 다릅니다. 데이터가 통째로 삭제되더라도 큰 지장이 없는 데이터만 저장해야 합니다. 중요한 데이터를 클라이언트에도 저장해두는 것은 보안 문제를 야기시킬 수 있습니다. 프론트엔드의 코드는 사용자에게도 공개된다는 점을 기억하셔야 합니다. 여기에 postgres 주소라도 적어놓으면 해커들의 엄청난 공격에 시달릴 것입니다. 클라이언트마다 각자 DB를 가지고 있기 때문에 사용자가 늘어날수록 부하도 심해질 겁니다. 데이터를 postgres에만 저장하는 방안을 생각해봅시다. 혹시 성능 때문에 indexedDB를 캐싱 용으로 사용하시는 건가요? 동기화 작업을 수행하는 순간 성능은 희생될 수 밖에 없습니다. 성능과 동기화를 동시에 챙기는 것은 어려운 것이 아니라 불가능한 과제입니다. 분산 데이터 저장의 트레이드오프에 대해서는 다음 글을 참조 부탁드립니다. https://velog.io/@skynet/%EC%84%B8%EC%83%81%EC%97%90-%EC%99%84%EB%B2%BD%ED%95%9C-%EB%B6%84%EC%82%B0-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%80-%EC%97%86%EB%8B%A4-%EB%B6%84%EC%82%B0-%EC%8B%9C%EC%8A%A4%ED%85%9C%EA%B3%BC-CAP-%EC%A0%95%EB%A6%AC 아무리 생각해봐도 싱크가 꼭 필요하다면 2-phase commit 이나 saga 패턴 같은 기법을 적용하시면 됩니다. 참고로 현재 구상중인 구조, 즉 한 DB의 트랜잭션 안에 다른 DB의 트랜잭션을 포함시키는 것은 유효한 대안이 아닙니다. indexedDB가 postgres를 호출하는 것을 허용한다고 가정해봅시다. indexedDB가 마지막 커밋에 실패하면 어떻게 해야 할까요? postgres에 이미 저장된 데이터를 삭제/수정해서 되돌려야 할 겁니다. 그런데 이 수정, 삭제 작업마저 실패하면 데이터의 싱크를 맞추는 것이 거의 불가능해집니다.