이벤트 중심 아키텍처에 적합한 도구 및 패턴 사용

이벤트 중심 아키텍처는 시스템 또는 응용 프로그램 상태 변경을 전달하는 이벤트의 효율적인 생산 및 소비를 지원합니다. 이러한 아키텍처는 시스템 간에 유연한 연결을 활성화하고 시스템 전체에서 작동하는 프로세스 및 실시간 업데이트를 지원합니다. 이벤트 기반 아키텍처의 장점은 쉽게 확인할 수 있지만 구현 세부 사항은 항상 명확하지 않습니다. 이벤트 중심 아키텍처 패턴에서 고려해야 할 기능은 무엇입니까? 이러한 패턴이 해결하는 특정 문제는 무엇입니까? 솔루션에 적용되는 특별 고려 사항은 무엇입니까? 솔루션을 해결하기 위한 최적의 패턴은 무엇입니까?

이 가이드는 Salesforce 기술을 사용하여 작업할 때 최적의 이벤트 중심 아키텍처를 구축하는 데 사용되는 패턴을 제공합니다. 또한 Salesforce에서 사용할 수 있는 예비 도구를 설명하고 사용 사례의 선택에 대한 도구 권장 사항을 제공합니다. Salesforce와 관련된 데이터 수준 통합에 대한 자세한 내용은 데이터 통합 결정 가이드를 참조하십시오.

• 요청에 대한 동기식 응답이 필요하지 않은 프로세스에 이벤트 기반 아키텍처를 사용합니다. 이 가이드에 설명된 패턴은 데이터 일관성, 확장성, 재사용을 위해 고안되었으므로 조직의 응용 프로그램 환경이 발전함에 따라 기술 부채를 최소화할 수 있습니다. (자세한 내용은 Well-Architected - Throughput을 참조하십시오.)

• MuleSoft 또는 다른 Enterprise Service Bus(ESB) 솔루션이 기존 환경의 일부인 경우 가능한 경우 이를 사용하십시오. 해당 솔루션은 이벤트 중심 아키텍처 패턴을 지원하도록 고안되었으며, 엔터프라이즈 전체에서 통합을 재사용할 수 있는 강력한 기능을 갖추고 있습니다.

• 스트리밍 API를 비롯한 다른 API를 사용하여 자체 이벤트 처리기를 구축하는 대신 향후 게시/구독 패턴에 Pub/Sub API를 사용하십시오. 이제 Pub/Sub API가 정식 출시되었으므로 새 게시/구독 패턴에 사용하십시오. 가능한 경우 스트리밍 API 또는 사용자 정의 Apex 서비스와 같은 다른 플랫폼 API를 사용하여 기존 이벤트 통신을 Pub/Sub API로 마이그레이션할 계획입니다.

• 플랫폼 이벤트 및 변경 데이터 수집(CDC)은 다른 시스템에서 사용해야 하는 레코드 및 필드 변경 사항을 게시하는 데 가장 적합한 메커니즘입니다. 새 구현에 PushTopic 및 일반 이벤트를 사용하지 않는 것이 좋습니다. Salesforce는 현재 기능 기능 내에서 계속해서 PushTopic 및 일반 이벤트를 지원하지만 이 기술에 추가 투자를 계획하지는 않습니다.

	Salesforce Platform은 직원, 자율 AI 에이전트, 회사 데이터 및 애플리케이션을 신뢰할 수 있는 단일 시스템으로 통합하여 생산성과 고객 경험을 향상시키는 종합적인 AI 기반 플랫폼입니다. 이를 통해 Customer 360 앱, Data Cloud, Slack을 연결하여 엔드 투 엔드 자동화를 수행할 수 있게 되었습니다.
	MuleSoft는 조직이 온 프레미스 및 클라우드 환경 전반에서 애플리케이션, 데이터, 장치를 연결할 수 있는 Salesforce의 선도적인 통합 플랫폼입니다. MuleSoft는 시스템 전반에서 데이터를 잠금 해제하고, 확장 가능한 통합 및 자동화 프레임워크를 개발하고, 차별화되고 연결된 환경을 빠르게 만들 수 있는 플랫폼을 제공하는 플랫폼입니다.

이벤트 중심 아키텍처(EDA)는 거의 실시간 알림이 필요하며, 대용량 또는 복잡한 메시지에 대한 처리 부하를 배포하고, 대기열을 통해 연결 복원을 필요로 하는 IoT 및 모바일 장치와 같은 시스템을 통합하는 시나리오에 권장됩니다. 그러나 비동기 실행을 위해 설계되었으므로 즉각적이고 동기식 인적 응답이 필요한 프로세스에는 EDA를 구현해서는 안 됩니다. 또한 소스 데이터가 너무 자주 변경될 경우 배치 처리와 같은 간단한 패턴이 충분하지 않을 경우 적합하지 않습니다.

다음은 이벤트 중심 아키텍처에 적합한 몇 가지 일반적인 시나리오입니다.

대부분의 대규모 조직에는 다양한 기능을 갖춘 시스템 조합이 포함된 복잡한 IT 환경이 있습니다. 조직에 이벤트 중심 통합을 지원하지 않는 레거시 시스템이 있을 수 있거나 특히 가능성이 높습니다. 또한 시스템에서 지원하는 경우에도 이벤트 중심 통합이 적합하지 않은 사용 사례가 있을 수 있습니다(예: 타사에서 SFTP 파일 전송). 이전 단계로 돌아가 조직의 전체 IT 환경을 살펴보면 다른 아키텍처 솔루션과 마찬가지로 다양한 시나리오를 지원하는 패턴의 혼합을 적용할 수 있습니다. 이벤트 중심의 기본 통합 접근 방식을 만들기로 결정할 경우 도구 상자의 다른 도구로 생각하십시오. 올바른 시나리오에서 사용할 수 있고 사용해야 하지만 모든 시스템에 적용되는 접근 방식은 아닙니다. 포괄적인 통합 전략을 개발하면 이 가이드에 설명된 패턴이 적절하거나 적절하지 않을 때를 판단하는 데 도움이 됩니다.

많은 시나리오에서 이벤트 기반 아키텍처가 필요하며, 일부 시나리오에서는 가장 적합하지 않은 경우에도 이벤트 기반 아키텍처가 작동합니다. 그러나 일부 시나리오에서는 이벤트 중심 아키텍처를 사용해서는 안 됩니다. 다음은 다음 시나리오를 식별하는 데 도움이 되는 몇 가지 결정 지점 질문입니다.

다양한 이벤트 중심 아키텍처 패턴이 있습니다. 일부는 이벤트 기반 이외의 특별한 요구 사항이 없는 사용 사례에 적용할 수 있는 일반 용도 패턴입니다(예: Well-Architected - Interoperability 참조). 다른 패턴은 여기에 설명된 특정 사용 사례에 적용할 수 있습니다(예: 대용량 데이터를 포함하는 통합 또는 메시지를 더 오래 보관해야 하는 시나리오).

아래 표는 이 문서에 요약된 패턴의 특성을 비교합니다. 지정된 사용 사례에 대한 잠재적인 패턴을 식별해야 하는 경우 빠른 참조로 사용합니다.

Salesforce는 이벤트 중심 사용 사례를 해결하는 데 도움이 되는 여러 가지 도구를 제공합니다. 이 표에는 사용 가능한 도구의 상위 수준 개요가 포함되어 있습니다.

핵심 응용 프로그램 내에서 중요한 레코드가 상태를 변경하는 경우(예: 주문 상태가 "처리 중"에서 "배송됨"으로 변경됨) 여러 다른 시스템에서 각 과업을 수행하기 위해 거의 실시간으로 알림을 요구할 수 있습니다. 이러한 변경 사항의 용량이 많고 메시지가 복잡한 경우 특정 비즈니스 요구 사항이 발생하므로 기존 지점 간 통합이 부담스럽고 유지 관리하기 어려울 수 있습니다. 모든 종속 응용 프로그램에 대해 취약한 사용자 정의 연결을 설정하면 기술 부채가 발생하고 조직의 신속한 확장 능력이 저하됩니다. 소스 시스템을 모든 소비 시스템에 직접 연결하지 않고 이러한 자주 발생하는 데이터 동기화를 관리하려면 강력한 통합 접근 방식이 필요합니다.

아래 다이어그램은 이벤트 버스를 통해 데이터를 공유하는 여러 게시자 및 구독자가 있는 일반적인 게시/구독 패턴을 보여줍니다. 이 기본 패턴은 이 가이드의 나머지 부분에서 찾을 수 있는 더 구체적인 패턴의 기반이 됩니다. 이 패턴의 일부 주요 특성은 다음과 같습니다.

• 게시자와 구독자 간에 직접적인 연결이 없습니다. 게시자는 이벤트 버스에 메시지를 보내기만 하면 해당 메시지를 수신하려는 다른 시스템으로 브로드캐스트합니다.

• 동일한 시스템은 게시자 및 구독자일 수 있습니다.

• 시스템에서 여러 유형의 이벤트를 게시하거나 구독할 수 있습니다.

• 이 가이드의 모든 패턴과 마찬가지로 게시/구독 패턴은 원격 절차 호출(RPI) 또는 단순히 "화면 및 잊기"로 알려진 일반적인 통합 패턴 범주에 속합니다.

조직이 모바일 장치에 푸시 알림 또는 SMS 메시지와 같은 대규모 클라이언트 응용 프로그램에 즉각적인 업데이트를 보내야 하는 경우 모든 단일 수신자에 대해 고유한 전송을 만드는 기존 프로세스가 빠르게 확장성 지체가 됩니다. 이 경우 핵심 비즈니스 요구 사항은 계정 경고 또는 중요한 서비스 변경 알림과 같은 단일 정보의 빠르고 고성능한 배포를 여러 엔드포인트 응용 프로그램에 동시에 수행하는 것입니다. 이 요구 사항을 충족하기 위한 간소화된 접근 방식은 모든 메시지를 단일 대기열을 통해 라우팅하는 것을 포함하며, 이는 모든 소비 시스템에 대한 이벤트 정보의 중앙 지점 역할을 합니다. 이 접근 방식은 여러 개의 별도의 메시지 사본을 관리할 필요가 없어 성능을 향상합니다.

fanout 패턴을 사용하면 단일 메시지 대기열을 통해 하나 이상의 대상(즉, 클라이언트 또는 구독자 수신)에 메시지가 전달됩니다. 구독자는 고유한 사본이 아닌 대기열에서 동일한 메시지를 검색합니다. 성능이 향상되지만 특정 구독자가 메시지를 수신했는지 여부를 확인하기가 더 어려울 수 있습니다.

일부 이벤트 시나리오는 동기화 및 변환 프로세스의 용량을 압도할 위험이 있는 메시지 볼륨의 상당한 유입 또는 이벤트 데이터를 처리하고 변환하는 데 필요한 복잡한 다단계 논리로 특징화됩니다.

일부 예는 다음과 같습니다.

• 계절 볼륨 급증: 선택 제품이 "계절에 있음"일 때 온라인 소매업체가 경험하는 볼륨이 급증할 수 있습니다. 많은 고객이 동시에 구매하는 경우 생성된 이벤트 수가 일시적으로 동기화 및 변환 프로세스의 용량을 초과할 수 있습니다. 자세한 내용은 Well-Architected - Data Handling을 참조하십시오.

• 사례 또는 청구 관리: 서비스 기반 회사는 중단 시 사례 또는 청구 수가 급증할 수 있습니다.

• 복잡한 데이터 변환: 메시지를 변환하기 위해 복잡한 논리가 필요한 조직은 변환할 수 없는 속도로 생성되는 이벤트가 걱정되는 경우가 많습니다.

이 패턴은 변환할 수 없는 속도로 메시지가 생성되는 문제를 해결합니다. 스트리밍 메시지 플랫폼을 통합하고 메시지 처리 논리를 전용 구성 요소에 세분화하여 대용량 메시지 및 필수 데이터 조작을 신뢰할 수 있도록 합니다.

전달된 메시지 패턴은 메시지 처리 논리를 여러 구성 요소로 세분화하여 작동합니다.

• 한 구성 요소가 메시지 라우팅을 처리하여 필수 변환 및 최종 대상을 결정합니다.

• 별도의 구성 요소 집합은 다양한 메시지 변환 계층(예: 필드 매핑, 개체 관계 등)을 처리합니다.

• 마지막 구성 요소는 최종 수정된 메시지를 작성합니다.

일부 프로듀서는 이벤트의 연속 스트림을 생성합니다. 일반적인 예로는 미디어 스트리밍으로서 자연스럽게 개별 이벤트로 발생하는 사용자 상호 작용이 수반됩니다. 핵심 스트리밍 환경을 차단하지 않고 여러 시스템이 동일한 사용자 동작에 동시에 반응해야 합니다.

음악 스트리밍 플랫폼에 대한 이벤트를 고려하십시오. 다음이 포함될 수 있습니다.

• 시작/일시 중지됨/ 건너뛰기 이벤트 추적

• 타임스탬프를 사용하여 세션 이벤트 듣기

• 재생 목록 만들기/수정 이벤트

• 소셜 공유 이벤트

• 오프라인 수신용 다운로드

스트리밍 패턴에서 구독자는 각 이벤트 스트림에 액세스하고 수신된 정확한 순서대로 이벤트를 처리합니다. 각 구독자에게 각 메시지 스트림의 고유 사본이 전송되므로 구독자별 콘텐츠를 전달하고 어떤 구독자가 어떤 스트림을 수신하는지 식별할 수 있습니다.

스트림을 이해하려면 모든 이벤트와 관련 메시지가 올바른 순서로 표시되어야 합니다. 다른 시스템에서 스트림의 데이터를 소싱하는 경우 추가 주문 논리를 설계 프로세스의 일부로 통합해야 합니다.

대기열 사용 사례는 모든 곳에 존재합니다. 예:

• 저품질 인터넷 연결: 해당 장치의 응용 프로그램이 대기열에 연결하고 연결이 복원되면 관련 메시지를 검색할 수 있으므로 Field Service 조직 또는 모바일 장치가 있는 팀이 품질이 낮거나 간헐적으로 인터넷에 액세스하는 영역에서 작업해야 하는 기타 조직은 대기열에서 혜택을 누릴 수 있습니다.

• 메시지 버퍼링: 메시지 용량이 구독자의 처리 용량을 가끔 초과하고 대기 시간이 증가하면 추가적인 문제가 발생하지 않으면 대기열이 초과 메시지를 저장하고 데이터 손실을 방지하는 버퍼가 될 수 있습니다.

• 교통 관리: 플리트를 모니터링해야 하는 물류 조직은 이 패턴을 사용하여 각 차량이 사용 중인 경로를 거의 실시간으로 보고 운전자가 가능한 한 효율적으로 작업하는지 확인할 수 있습니다.

• IoT 장치: 제조업체는 빠른 데이터 스트림을 생성하는 시스템을 자주 사용하며, 해당 스트림은 추가 시스템에 다운스트림 영향을 미칠 수 있습니다. 이 패턴은 여러 시스템에 걸친 재해적 오류가 발생하기 전에 사람이 개입해야 하는 이벤트의 시퀀스를 식별하는 데 사용할 수 있습니다.

대기열 패턴에서 프로듀서는 대기열에 메시지를 보내고, 구독자가 메시지를 검색할 때까지 메시지를 보관합니다. 대부분의 메시지 대기열은 FIFO(Primer In, First Out) 순서를 따르며 검색 후 모든 메시지를 삭제합니다. 각 구독자에게는 고유한 대기열이 있으므로 추가 설정 단계가 필요하지만, 배달을 보장하고 어떤 구독자가 어떤 메시지를 수신했는지 식별할 수 있습니다.

대기열 패턴의 비동기적 특성으로 인해 대기열에 추가되는 메시지와 검색되는 메시지 사이에 긴 지연이 있을 수 있습니다. 대기열에는 메시지를 보관하는 메모리 또는 저장소 공간이 필요하므로 무기한으로 증가할 수 없습니다. 즉, 대기열에 메시지가 충분히 구축되면 무기한으로 오프라인 상태인 구독자가 실패할 수 있습니다. 구독자 처리 시간이 너무 길면 메시지 버퍼링이 동일한 영향을 미칠 수 있으므로 대기열에 많은 양의 메시지가 구축됩니다. 이러한 위험을 완화하려면 모든 메시지 대기열에 대한 철저한 저장소 요구 사항 분석을 수행하고 필요한 경우 메시지가 설정된 시간 내에 검색되지 않거나 사전 결정된 볼륨에 도달하면 대기열을 제거하고 비활성화하는 프로세스를 설계합니다.

이벤트 기반 아키텍처가 조직에 적합하다고 확신하는 경우에도 이미 많은 지점 간 통합이 있는 환경에서 시작할 수 있습니다. 모든 통합을 한 번에 대체하기 위해 프로젝트에 대한 자금을 확보하는 것은 어려울 수 있으며 일부 레거시 시스템에서 이벤트 중심 아키텍처를 직접 사용할 수도 없습니다. 이러한 시나리오에서 가장 비즈니스에 중요한 응용 프로그램을 먼저 변환한 다음, 향후 프로젝트에서 업데이트되거나 교체될 때 다른 시스템을 변환하여 더 느슨하게 연결된 아키텍처로 마이그레이션하는 증분 접근 방식을 취할 수 있습니다. 이 접근 방식을 통해 이벤트 버스에 새 응용 프로그램을 쉽게 추가할 수 있으며, 시간이 지남에 따라 시스템이 계속해서 추가되면서 전반적인 IT 환경이 확장 가능하고 복원 가능해집니다.

설계자는 모든 아키텍처에 제약이 있다는 사실을 알고 있습니다. 이벤트 중심 아키텍처는 예외가 아닙니다. 매끄럽게 연결된 시스템으로 가득한 환경은 확장성이 높고 복원성이 뛰어나지만 고려해야 할 몇 가지 제약 사항도 있습니다.

• 전체적 통합 전략: 사용하기로 결정한 도구 및 패턴과 상관없이 조직의 다양한 시스템에서 데이터를 공유하는 방법에 대한 전략을 시작하는 것이 중요합니다. 이 전략에는 조직의 데이터 목표, 데이터를 공유할 수 있는 방법, 사용되는 패턴, 데이터 소스, 목표, 구조, 소유권 및 액세스 요구 사항이 포함되어야 합니다.

• 레거시 시스템 지원: 조직에 단순히 이벤트 중심 아키텍처 패턴을 지원하지 않는 기존 시스템이 있을 수 있습니다. 해결 방법을 구축할 수 있지만(예: 이벤트를 구독한 후 다른 데이터 전송 수단을 통해 대상 시스템에 출력을 보내는 방식으로 진행 방법으로 작동하는 프로세스) 이 경우 다른 통합 방법을 고려할 수 있습니다.

• 메시지의 구조적 변경: 게시자와 구독자 간에 초기 메시지 구조가 정의되고 동의되면 특히 구독자가 외부인 경우 변경하기 어려울 수 있습니다. 이 문제를 해결할 수 있는 몇 가지 방법이 있습니다. 버전이 지정된 끝점을 사용할 수 있지만 개발자가 너무 많은 버전을 동시에 유지할 필요가 없도록 각 버전에 대해 명확한 수명 주기를 정의하고 전달해야 합니다. Heroku의 아파치 카프카가 가로에 속하는 경우 스키마 레지스트리 또는 유사한 도구도 고려할 수 있지만 가로에 있는 다른 시스템에서도 지원하고 사용해야 합니다.

• 발행자와 가입자 간의 가시성 부족: 대부분의 이벤트 중심 아키텍처 패턴에서 게시자는 구독자의 상태를 인식하지 못합니다. 따라서 모든 구독자가 오프라인 상태인 동안 게시자가 중요 메시지를 보내는 경우 메시지가 전달되지 않을 수 있습니다. 재생 기능을 사용하거나 모든 중요 메시지에 대해 별도의 서버에서 실행되는 중복 구독자를 추가하여 이 문제를 해결할 수 있습니다.

• 성능 병목: 이벤트 중심 아키텍처가 확장되면 너무 많은 게시자가 동시에 너무 많은 구독자에게 메시지를 보내려고 하면 이벤트 버스가 메시지 전달의 지체가 될 수 있습니다. 이벤트 버스에 할당된 메모리 및 처리 자원을 늘리거나 여러 이벤트 버스를 사용하여 다양한 유형의 메시지를 병렬로 처리하여 문제를 해결할 수 있습니다.

이벤트 기반 아키텍처를 구현하기 전에 먼저 실제로 사용해야 하는지 고려하십시오. 이전 섹션에서는 각 이벤트 중심 아키텍처 패턴에 적합한 일반적인 비즈니스 시나리오를 설명합니다. Well-Architected - Interoperability 에서 자세히 읽을 수 있습니다. 이벤트 기반 아키텍처를 구현할 때 고려해야 할 챌린지를 검토하여 고려하는 패턴이 특정 사용 사례에 가장 적합한지 판단합니다.

이 가이드에 포함된 대부분의 시나리오에는 통합이 포함되어 있지만 이벤트 중심 아키텍처를 사용하여 예를 들어 플랫폼 이벤트를 사용하여 단일 Salesforce 조직 내에서 메시지를 보낼 수도 있습니다. 플랫폼 이벤트를 내부 메시징 시스템으로 사용하는 프로세스를 설계할 때 해당하는 이벤트 할당 제한을 고려하십시오.

이벤트 중심 아키텍처에 대한 안티 패턴은 Salesforce 조직 내에서 내부 커뮤니케이션에 대한 해결 방법으로 이벤트를 사용하여 발생하는 경우가 많습니다. 일반적인 안티 패턴은 다음과 같습니다.

• 동일한 이벤트 개체와 연결된 Apex 트리거에서 이벤트 게시: 이렇게 하면 무한 트리거 루프가 생깁니다.

• DML 트랜잭션이 완료되기 전에 Apex에서 이벤트 게시: 트랜잭션이 실패하고 롤백되는 경우 즉시 게시 동작이 있는 게시된 이벤트는 롤백 동작에 포함되지 않습니다.

• 다음 자동화를 오케스트레이션하기 위해 Flow에서 이벤트 게시: 여러 자동화 간에 논리를 조정하는 가장 좋은 방법은 하위 플로 또는 플로 오케스트레이터를 사용하는 것입니다.

• 런타임 종속성 만들기: 런타임 종속성을 제거하기 위해 적절한 단계를 취하지 않고도 패키지 간의 통신을 촉진하기 위해 이벤트를 게시하지 마십시오.

• 불필요하게 큰 페이로드: 요청할 때 페이로드에서 가능한 한 적은 양의 데이터를 보내서 받는 것이 가장 좋습니다. 사용자의 모든 작업이 잠재적으로 여러 요청을 생성할 수 있으며, 해당 요청을 효율적으로 처리하는 것이 중요합니다. 필요보다 많은 데이터를 보내도 전송 속도가 느려지고 처리 시간이 늘어날 수 있습니다.

• 응용 이벤트의 무선 처리: 응용 프로그램 이벤트를 수신하는 구성 요소가 여러 개인 경우 개발자는 이벤트 처리기가 실제로 원하고 유용한 경우에만 실행되는지 확인해야 합니다. 예를 들어 Lightning 콘솔에서 포커스가 맞지 않은 탭에 포함된 구성 요소는 보이지 않더라도 여전히 청취할 수 있습니다. 개발자는 백그라운드 유틸리티 항목을 유일한 수신자로 사용하거나 getEnclosingTabId() 호출과 같은 다양한 기법을 사용하여 이 구성 요소의 인스턴스가 초점이 맞춰진 탭 내에 묶여 있는지 여부를 판단하여 각 이벤트가 의도한 경우에만 처리되도록 할 수 있습니다.

• 플랫폼 이벤트를 사용하여 잘못된 게시 동작: 플랫폼 이벤트에는 즉시 게시 및 커밋 후 게시의 두 가지 게시 동작이 있습니다. 트랜잭션 성공 및 커밋 여부와 상관없이 로깅 이벤트를 게시하려는 사용 사례에 실시간 플랫폼 이벤트를 사용할 수 있습니다. 그러나 실시간 플랫폼 이벤트에 Publish Immediately를 매우 주의 깊게 사용하십시오. 이벤트는 같은 트랜잭션 내에서 구독자가 소비할 수 있으며 행 잠금 또는 기타 경쟁 조건을 야기할 수 있습니다.

이벤트 중심 아키텍처를 구현할 때 성공의 핵심 중 하나는 이벤트 자체가 설계되는 방법에 대한 표준을 설정하는 것입니다. 세부 사항은 조직의 사용 사례에 따라 다르지만 다음은 몇 가지 일반 지침입니다.

• 이벤트 페이로드에 최적의 구조를 결정합니다. 메시지 크기가 작을수록 처리 시간이 줄어들지만, 메시지 볼륨이 대량인 구독자를 폭격하면 성능 지체가 발생할 수 있습니다. 적절한 균형을 찾으려면 페이로드 크기 및 구조를 반복해야 할 수 있습니다. MuleSoft 및 유사한 ESB 도구는 이벤트와 관련된 메시지에서 사용자 정의 페이로드를 설계할 수 있는 기능을 제공하며, 이를 통해 데이터 구조를 시각화하여 구독자 측의 성능을 개선할 수 있습니다. (자세한 내용은 Well-Architected - API Management를 참조하십시오.)

• 단계별로 프로세스를 생각해 보십시오. 통합이 롤아웃되면 추적하기 어려울 수 있는 "무종일 루프" 시나리오를 만들지 마십시오. 이러한 예는 레코드가 업데이트될 때 이벤트를 게시하는 두 시스템이며, 레코드가 처리될 때 추가 게시된 이벤트를 트리거하는 서로의 이벤트를 듣는 동시에 있습니다.

  소비되는 이벤트로 인해 변경된 논리를 통해 새 이벤트가 게시되지 않도록 두 시스템 모두에 추가하여 이 유형의 안티 패턴을 수정할 수 있습니다. 모든 이벤트, 관련 트리거, 영향을 받을 수 있는 다운스트림 시스템도 문서화해야 합니다. 설계 세션 중에 이 문서를 참조로 사용하여 가능한 한 빨리 무한 루프 및 유사한 시나리오를 파악할 수 있습니다. (자세한 내용은 Well-Architected - Process Design을 참조하십시오.)

• 시스템 간 공통 명명 규칙 사용하기. 일관된 명명 규칙은 이벤트 중심 아키텍처를 포함하여 모든 소프트웨어 개발에 대한 모범 사례입니다. 이벤트 이름, 구조, 관련 개체, 오류 처리 프로세스에 대한 일관성을 보장하기 위해 시간을 내어 일련의 표준을 문서화합니다. (자세한 내용은 Well-Architected - Design Standards를 참조하십시오.)