Feature Overview (aka. Goal Summary)

Backstage is shifting toward an event-driven system rather than relying solely on periodic refreshes (e.g., in the catalog system). We should investigate which plugins could benefit from using the Event System and outline potential areas for integration.

Goals (aka. expected user outcomes)

• Plugins will no longer rely on constant polling, reducing network overhead and load on back-end services.
• Users receive more immediate notifications and updates from plugins (e.g., catalog changes, documentation updates).

Requirements (aka. Acceptance Criteria):

• Investigate the upstream events system in the context of supported plugins
  • Test current event modules upstream within RHDH
• Identify Candidate Plugins:
  Review existing Backstage plugins to determine which ones could benefit from event-driven architecture.
  Some candidates could be Catalog Processors ( Event-driven updates instead of periodic reprocessing) and Auth & Identity Plugins (Handle user/group syncs via events instead of batch jobs)
• Proof of Concept (PoC): Develop a PoC to demonstrate the feasibility of event-driven updates in selected plugins.

Documentation Considerations

• Document the event modules system in the upstream

Additional Context for Event System Integration that might be helpful while working on this feature:

• The fundamental event handling logic is defined in @backstage/plugin-events-node.
• @backstage/plugin-events-backend extends this core functionality by providing HTTP-based event ingestion capabilities, enabling external systems to publish events to Backstage.
• Upstream Documentation for Events System is currently distributed across various README files, suggesting a potential need for consolidated and improved documentation.