Use Case

EventCatalog's container_type enum (defined in packages/core/eventcatalog/src/content.config.ts and re-validated in packages/linter/src/schemas/data-store.ts) is currently storage-heavy:

database | cache | objectStore | searchIndex | dataWarehouse | dataLake | externalSaaS | other

This forces two very common kinds of C4 containers in modern event-driven architectures to fall back to externalSaaS (or other):

1. Message buses / brokers — Kafka, NATS, RabbitMQ, AWS SQS/SNS, Google Pub/Sub, Azure Service Bus, Solace. The current RFC RFC: Containers in EventCatalog #1819 even uses Kafka in its example flows ("OrdersService → OrderCreated → Kafka → Data Warehouse"), but a Kafka container has no native type today — it has to be tagged externalSaaS (misleading for self-hosted Kafka) or other (loses meaning).
2. Workflow / orchestration engines — Temporal, Airflow, AWS Step Functions, Cadence, Dagster, Prefect, Camunda. These are first-class containers in orchestrated architectures: they receive signals, drive state machines, and emit events.

Concretely, in our catalog we have ~12 Kafka clusters and 3 Temporal deployments. Tagging all of them externalSaaS makes filtering, grouping, icons, and docs lose their meaning.

C4's container concept is "any application or data store that needs to be running" — not only storage. Two narrowly scoped enum values would close this gap without going down the slippery slope of identityProvider, secretsManager, apiGateway, etc.

Proposed Solution

Add two values to the container_type enum:

 const containerTypeEnum = z.enum([
   // Core
   'database',
   'cache',
   'objectStore',
   'searchIndex',
   'dataWarehouse',
   'dataLake',
+  'messageBus',
+  'workflowEngine',
   'externalSaaS',
   // Fallback
   'other',
 ]);

Suggested semantics for the docs:

• messageBus — message brokers and event streaming platforms (Kafka, NATS, RabbitMQ, SQS/SNS, Pub/Sub, Service Bus, Solace).
• workflowEngine — durable workflow / orchestration engines (Temporal, Airflow, Step Functions, Cadence, Dagster, Prefect, Camunda).

Self-contained, additive, and orthogonal to the existing values. Existing catalogs are unaffected.

Implementation Notes

The enum is duplicated in a few places. A PR would touch:

• packages/core/eventcatalog/src/content.config.ts — Zod source of truth (containerTypeEnum, ~line 478).
• packages/linter/src/schemas/data-store.ts — independent linter copy of the enum (also currently missing 'other' — happy to fix that drift in a separate PR if preferred).
• packages/sdk/src/types.d.ts — Container.container_type union type.
• packages/language-server/src/ec.langium — ContainerTypeEnum grammar rule (and the regenerated ast.ts / grammar.ts).
• packages/playground/src/monaco/ec-language.ts — Monaco keyword list.
• packages/language-server/specification/08-container.md and the equivalent docs pages that enumerate valid types.
• Tests for the schema and linter.

I'd keep the PR strictly to the two added values — no refactoring, no surrounding cleanup, no rename of existing values.

Relationship to RFC #1819

This is intentionally scoped much narrower than the containers RFC (#1819). It doesn't touch container hierarchy, top-level placement, send/receive semantics, or domain assignment — just two missing values in the existing enum that would benefit any implementation path the RFC lands on.

Happy to defer if the RFC plans a different shape entirely (freeform string, separate categorisation field, etc.) — flagging that as the main open question below.

Open Questions

1. Are you open to extending the enum, or do you prefer to keep it small and push messaging/orchestration into a separate categorisation field (or freeform string)?
2. Naming: messageBus vs messageBroker vs eventStream? workflowEngine vs workflowOrchestrator?
3. Should this wait until RFC RFC: Containers in EventCatalog #1819 lands, or is it safe to merge ahead since it's purely additive?

If the direction looks good, happy to open the PR.

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.
• If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out in the EventCatalog Discord.