If you build a whole (micro) service universe you will soon notice a need for events triggered from one system and sent to another.

This can - and is - often handled as Rest-api's on two systems that call each other. While this strategy may get the job done you have an issue with the two systems must know about the other - and this is quickly turns into a spaghettis tangled web of services that cannot really change without breaking something else.

A much better approach is to have the more generic of the two systems expose a generic callback - an event.

Such events best implemented by an open socket that can be used by the generic system to signal events - that in turn may cause action in the caller.

realtimesubscribetoevent

realtimetriggerevent