We have many internal apps. If app1 needs data from app2, it must listen to events emitted by app2 and save the data in its db.

I have serious concerns, but my arguments have not been convincing. Your opinions/thoughts about this would help me greatly; especially any direct experience with this kind of architecture.

It's call "event sourcing", and it is occasionally useful. The main upside is that in most cases, it moves responsibility and cost to the consumer.

I've had to implement something like that in the past, when I had to interface to self-hosted JIRA instance - we had API access, but it was pretty slow, and any sort of complex queries would bring server to knees. I've ended up making a process which constantly syncs JIRA changes to our internal database, and then we could query our DB as much as we wanted.

So you probably want to find out what was motivation for the rule. And I am pretty sure it would be some sort of corporate dysfunction:

Maybe app2 is rarely-used, so it is running on cheap servers - while app1 will have significantly more hits. And app1 developers decided to be lazy and make 20 API calls to app2 for each page load. And in the past, this caused app2 to go down, which caused a whole bunch of shouting and finger-pointing, so management said: "ENOUGH! Everything goes through the event bus"

Maybe app2 maintainers cannot be trusted to keep servers up, and have accidentally destroyed their own servers, twice, causing company-wide outage in mission-critical app1. So management does not want a repeat of that.

Maybe IT department forces everyone onto in-house VM orchestrator, and it loves doing day-long maintenance/upgrade events on random servers. This caused extreme outages in the past, so management forced everyone to break dependency.

Maybe the corporate security director read in the trade magazine that open ports are bad, and decided that they do not trust any random developer to listen even on the internal network, only the blessed application - the event bus - can be trusted to listen for connections. (Of course you can get compromised via event bus message, but that director is too clueless to realize this)

Maybe a Super Principal Developer Plus wrote / set up that event bus themselves, and they have enough influence to force it on everyone...

I can keep guessing and guessing, so the first thing to do is to figure out why this rule was made, and what is the motivation for it. This will let you know of the best strategy to fight it.

So every app broadcasts all its data to every other internal app?

Mandatory, irregardless of the data and the app?

If so, the downsides I can see are:

- If there really is absolutely no API / way to request data, an app can of course only work on the data generated since it was first run (nothing older), and while it was running (apps downtimes will result in data holes), and that was delivered successfully; inconsistencies and data divergences among the apps are practically guaranteed. But maybe it's allowed to issue events to request arbitrary data?

- It's probably significantly easier to exfiltrate sensitive data

- Increased workload of the apps for having to constantly broadcast every single datum

- Probably a lot of wasted storage for the data's duplication

- Data stagnation, if the broadcasts are not careful to include updates and deletions

- Possibly significant unnecessary persistent network usage (which could also result in worse network performance)

- Persistent data divergence in case of corruption of an app's local db

The only advantage I can see is that an app's workload won't increase with the increase of the usage of its data by other apps, but the downsides are much more significant, in my opinion.

Maybe they also think that broadcasting can reduce network usage, but when you're doing it for every single datum, even if no one needs it, it sure won't have that effect.

And you can potentially broadcast/multicast even if you use APIs, with the big advantage that you can limit it to the data that's really used, and (with multicast) to the apps that do use it.

It seems some ideological take, possibly by some architect that read about it on some book.

It's probably a variation of Event-driven architectures; by reading about them you might have more success in convincing the higher-ups of changing something.

Caching data and broadcasting events can sure be appropriate in some cases, but mandating it a priori for everything, maybe without even a way to request missing data, seems unreasonable to me.

I do not have direct experience with something like this, though.