Integration pattern: API vs events

Question

I need to design the architecture of a CRM "platform" that integrates 5-6 legacy CRMs. One important feature is to show customer records stored in other CRMs in one single dashboard. The actual records are stored end edited in their own CRM.

One question is: should I store a minimal set of information about those records or not at all? A solution could be:

1. call each CRM API, assemble everything in a BFF and serve the result to the the CRM UI of the platform.

2. Another solution could be to send create/update events from each CRM to a service bus, subscribe the platform to those events and store minimal information into the platform CRM, like externalID, customer name, CRM type.

What are the pros/cons of each solution? not only from a technical standpoint, but also from a development team standpoint?

I would expect more requirements on the platform CRM side, but we don't know yet, so it must be extensible. For example, in the integrated platform, there could be a merge function where a user marks records as equivalent. Or some kind of workflow that apply to all records.

I don't have a strong opinion now, except that events look more decoupled" but more complex to implement.

Any suggestion on how to write an analysis welcome

Answer 1

I guess it depends on your end goal. If you just want a way to compare the various systems then you simple 'call each api in turn' plan might work.

However, if are trying to replace legacy systems, or offer a 'unified source of truth' or something along those lines then having your own database is probably a must and pushing events to it would be superior to polling

Even with a simple comparison you will probably need some extra fields that link the various records, perhaps you have a "linking process" where the computer attempts to link the customer by something concrete like a national id, but has to fall back to name/dob or even potentially a human confirmation. You wouldn't want to run that process every-time the user hits refresh and would have to store that linking info somewhere.

Answer 2

Events are easier to test They're easier to reason with for pure functions An event can be harder to integrate into an existing architecture due to legacy decisions that have expected a monolithic or microservice API interaction

APIs on the other hand are easier to deploy, as all versioning strategies will work, event architecture relies on being ahead of a publishers version changes, i.e. the event consumer must be able to process prior versions and also simultaneously have prepared to process the next version ready for when the publisher updates, or the consumer will fail when new events arrive Whereas an API can do a long list of deployment options for the specific scenario you have. Inherently an event publisher changing without synchronised updates to consumers means consumers can't operate as expected, unless a producer sends the same event using multiple versions which can result in duplicate data being processed

Security characteristics of event architecture is biased towards the producer, as it isn't able to process arbitrary requests minimising both the attack surface and the load on the server. Also, a producer can protect the contents of the message using a JWT or HMAC (Both common for webhooks and event data) so sending/broadcasting data can only be read in cleartext by thise holding the keys, making data protection a PKI problem to silve and not the 100 API data protection problems