kth990303
commented
8 months ago *경원님 공유 어쩔 수 없이 결합도가 높을 수밖에 없는 상황도 존재한다.
- 연결돼있는 비즈니스 로직 (ok 를 받아야만 다음 기능 수행할 수 있는 케이스)
결합도를 낮출 수 있는 케이스
- 상대 응답과 무관하게 다음 로직을 수행해줘야 되는 케이스, kafka와 같은 MQ로 결합도를 낮출 수 있음.
- kafka로 데이터를 쏴주기만 하면 된다. 타 서버와의 의존성도 매우 낮아짐.
- HTTP API를 사용한다면 양방향 통신 및 불필요한 응답 받는 cost 존재
kafka consumer에서 polling 후 타 서버에 보내는 케이스, 실패한 경우 DLQ 에 넣는데
- 오염된 데이터의 경우 dlq에 넣어도 어차피 계속 잘못된 로직 수행하게 됨.
- dlq 제거 후 무한 retry 방식으로 변경
- 실시간성이 요구되지 않는 급한 건이 아니었으므로 오염되지 않은 성공 케이스가 올 때까지 무한 retry
- 오염된 데이터를 보내는 측에서의 수정만 있으면 제대로 돌아감.
- 무한 retry 방식으로 했을 때, 영향도가 큼.
- 문제가 되는 케이스를 dlq에 넣게 되면 영향도 전파는 적어짐.
- 단, 우리의 리소스는 뺏기게 됨 -> 하지만 영향도 전파는 적어지므로 우리가 조금 고생하더라도 이게 맞지 않을까?
- DLQ 내부 로직, DLQ 성능 고려 필요
질문
여러분의 시스템에서 결합도가 높아서 균열 전파 가능성이 높은 지점이 있으신가요? 균열 전파 가능성을 낮추기 위해 어떤 장치를 두셨나요?
연관 챕터
7
@caffeine-library/readers-release-everything