Sharing identical events, with differing scopes, between client and server libraries, in a micro-service architecture

Question

I have a shared user repository (id, name, e-mail, password, etc.) exposed as a REST service - and multiple independent websites accessing this REST service (from the back-end) as a means of sharing a common user base across multiple sites.

I have a local, in-memory event bus (pub/sub) as part of the REST server implementation - it publishes events such as UserCreated, UserDeleted, etc. which enables me to plug in new listeners that perform various actions, such as sending out notification e-mails, etc.

As part of the REST client implementation, I also have an event bus, with the same events, such as UserCreated, UserDeleted, etc. - these events have the same shape and payload, but they don't have the same scope.

That is, if a user is created on site A, the UserCreated event is triggered on client A, and when it accesses the REST API on the server, the UserCreated event is triggered on the server, but the event, of course, does not occur on site B, and vice-versa.

If the events on the server and clients have the same shape and payload, and only differ in terms of scope, I can put these event implementations in a shared library and reuse them in the client and server implementations.

My concern is that, because event listener implementations would be interface-compatible, it might mislead other developers to expect that these events would also occur with the same frequency when plugged into the REST server or a REST client.

On the other hand, if they're compatible, I could write an e-mail notification listener once and plug it into the REST server, to send sign-up notifications to an admin - and plug the same implementation into REST clients, to send welcome e-mails to new users.

Is it okay to reuse these event implementations, even though they do not have the same scope?

Or should I duplicate the event implementations, in the REST client and server libraries respectively, to make sure other developers understand that the events, although identical in shape, do not have the same scope?

Bottom line, what defines an event? Is it defined by its shape and payload, or is it also defined by its scope, even though a change in scope produces no tangible difference in terms of shape or payload?

• Ixrec: Strange that this still hasn't gotten even a comment. So, when you say "reuse these event implementations", are we talking about a header file included by client and server code, or a small POD data structure that has to be defined in one server language and one client language, or a complex class with lots of behavior that has two definitions? Or something else? (my immediate instinct is that unless the different frequency justifies a very different implementation, there's no point in not sharing the code)
• mindplay.dk: I still have no answer to this. I guess the question really boils down to: what defines an event? Is it defined only by the shape and payload of the event itself, or is it also defined by it's scope, even if a change in scope produces no tangible difference in terms of shape or payload?
• Ixrec: The key aspect of "events" as I understand them is that the thing firing events does not know or care who is listening to them. In order for that to be useful, anyone who may want to listen needs to know when the event will be fired and what it will contain. So at the abstract level you're talking about I'd say it's "defined by its payload and not its scope".
• mindplay.dk: By scope, I don't mean who's listening, or even who's capable of listenening - which may not be possible if the event fires on a different server. What I mean by scope is when (under what condition) does the event fire? If, by definition, an event fires when any user is created, is that the same event as one that fires only when some users are created? Of course, yes, events are broadcast, so by definition we don't (shouldn't) know if anybody is listening - but we're actually talking about what gets broadcast, not to whom, right?
• Robert Perry: I still have no answer to this. I guess the question really boils down to: what defines an event? - The answer to that is dead simple. "This happened" .. Its a statement about something that occurred in the past. They typically follow a past tense naming convention. For example. UserCreated, UserDeleted, OrderAccepted, OrderDeclined, PaymentAccepted, PaymentDeclined. Often I see developers getting this wrong and using names such as CreateUser, CreateOrder. They, are commands. To answer you point directly; it doesnt matter who/what is listening for the event, you're saying - this happened.