귀하의 필요에 맞는 맞춤형 FinMV 견적에 대해 문의하십시오.
회사의 기술 이사는 금융 플랫폼 출시를 계획할 때 프로젝트 아키텍처 옵션을 선택해야 합니다. 어떤 아키텍처 옵션을 사용할 수 있으며 어떤 것을 선택하는 것이 더 낫습니까?
새로운 투자 플랫폼에는 하나의 팀, 하나의 배포, 하나의 데이터베이스가 있습니다. 이 단계에서 분산 시스템의 비용은 전부 오버헤드로 소모됩니다. 함수 호출로 충분한 곳에 네트워크 호출을 하고, 트랜잭션으로 충분한 곳에 최종적 일관성을 쓰고, 아무도 담당할 인력이 없는 운영 부담을 지게 됩니다.
그래서 기본 구현 방식은 모듈형입니다. 온보딩, 오퍼, 투자, 결제, 문서, 서비스, 리포팅은 하나의 배포 가능한 시스템 안에서 명확한 경계 뒤에 존재합니다. 이를 모듈형으로 만드는 것은 폴더 구조가 아니라, 각 모듈이 계약을 가지고 있고 자체 데이터를 소유하며 자체 테스트로 검증된다는 사실입니다.
모듈은 구체적인 근거가 있을 때 독립된 서비스가 되며, 그 근거는 유행이 아니라 비즈니스적인 것입니다.
경계와 계약이 이미 존재하기 때문에, 서비스 분리는 재작성이 아니라 계획된 작업이 됩니다. 바로 이 점이 핵심입니다. 선택지는 계속 열려 있고, 비용도 낮게 유지됩니다.
사용자를 막아서는 안 되는 작업 — 정산 대조, 문서 생성, 제공업체 콜백, 리포팅 — 은 큐를 통해 처리됩니다. RabbitMQ나 Kafka 같은 메시지 브로커는 처리량이나 통합 토폴로지가 이를 정당화할 때 도입되는 것이지, 기본값이 아닙니다. PostgreSQL은 계속해서 기록 시스템으로 남고, Redis는 저지연 캐시나 조정이 실제로 필요한 곳에서 사용됩니다.
저희는 모놀리스도 판매하지 않고, 마이크로서비스도 판매하지 않습니다. 둘 다 아직 아무도 묻지 않은 질문에 대한 답일 뿐입니다. 또한 그럴듯해 보이기 위해 분산 시스템을 구축하지도 않습니다. 아키텍처 극장은 운영 비용이 비싸고 인수인계하기도 어렵습니다.
아키텍처는 귀사의 규모, 규제 의무, 통합, 그리고 이를 운영할 팀의 규모에 따라 선택되며, 이러한 것들이 변화할 때 함께 변화할 수 있도록 설계됩니다.
