Internal Event

An event used within a single service or bounded context, not exposed to other teams or systems.

An internal event is an event that stays within the boundaries of a single service or bounded context. It's not part of any public contract with other teams or systems. You can change its schema, rename its fields, or remove it entirely without coordinating with anyone outside your team.

This is different from events that cross service boundaries. Once an event becomes a contract between teams, changing it gets expensive. You need versioning strategies, migration plans, and buy-in from consumers you might not even know about.

Internal events are useful for decoupling logic within a service. For example, when an order is placed, you might want to update inventory, send a confirmation email, and log an analytics event. Instead of putting all that logic in one function, you publish an internal OrderPlaced event and let separate handlers react to it. The publishing code doesn't need to know about any of the subscribers.

You can implement internal events with an in-process Pub/Sub (like Go channels) or with a persistent one (like a database-backed queue). The choice depends on your durability requirements. If losing an event on a crash is acceptable, in-memory is fine. If not, store it with the Outbox pattern and process it asynchronously.

The important distinction is scope, not technology. An internal event and a public event might use the same infrastructure. What makes an event "internal" is the decision that it belongs to one team and can evolve freely.

Keep internal events internal. When another team starts consuming your internal event, it quietly becomes a public contract. At that point, refactoring is no longer cheap. Be intentional about which events you expose and which ones stay private.