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

2 Answers 2


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.

  • I've got the kind of feeling that the API plan will lead to more coupled systems, also from a development point of view. I feel more comfortable with a team developing an API backend for an actual DB. But I can't express this feeling properly as a technical decision
    – Glasnhost
    Nov 6, 2021 at 10:53
  • also what about adding more integrated systems? In case of events, it will be enough for the new system just to publish events in a standard way to the bus. Otherwise, I would need to expose an API, add the API call and modifying the merging part...
    – Glasnhost
    Nov 6, 2021 at 11:03
  • also, what about integration tests? if I have a BFF calling several APIs on external systems, I will need to run integration tests for all those systems. While with events, my platform will only care about its own frontend-backend integration
    – Glasnhost
    Nov 6, 2021 at 11:08
  • events vs api calling wont affect integration, either way you have work to do. tbh I would question the ability of random systems to push events, vs you programming a polling and conversion interface
    – Ewan
    Nov 6, 2021 at 11:45

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

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .