eventual icon indicating copy to clipboard operation
eventual copied to clipboard

Feat: Event segregation and permissions

Open thantos opened this issue 2 years ago • 0 comments

A developer should have control over which events are published outside of the service (service to service subscribe).

When a developer uses service to service subscription, the subscribed events should not be consumed by other subscribers.

graph LR;
   B --subscribes to--> A
   C --subscribes to--> B
  • A does not subscribe to any service. It's internal events should not appear in Service B.
  • B subscribes to A, it should not get internal events for A, but any non-internal events from A. It's internal events and events from service A should not appear in Service B.
  • C subscribes to B, it should only get outgoing events from B and no events from A.

  • Event Bus already does not support multiple bus hops (A to B to C wouldn't work if we wanted it to)
    • To do this, a consumer needs to manually forward events by re-publishing them as their own events.
  • if an Event is not exported from the top of the service, it is considered internal
    • these events can be handled by the service, but a rule cannot be added from outside (see below)
  • internal events - have the source eventual:[service name]-jinternalj
  • external events (non-internal) - have the source eventual:[service name]
  • Add a policy to the bus that says rules created by outside buses must contain the source === [service name]. https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-conditions.html
  • update subscribe and docs to only use the eventual:[service name] as the source type

  • Could we just use eventual:service and eventual:service-internal? yes, but it wouldn't be clear to consumers what the service name was. Using the service name allows for further consumer internal routing,
  • What stops consumed events from flowing downstream? - EB said it will not do multiple hops and bus to bus rules cannot transform.
  • What if a service wants to forward events from another service? this would be a separate feature. It is possible today by creating a handler and using publishEvent

thantos avatar Feb 09 '23 17:02 thantos