Part 035 — Workflow and Kafka Integration

Goal: integrate Camunda workflow with Kafka without confusing orchestration with event streaming, without losing correlation, and without creating replay-unsafe business side effects.

Kafka is excellent for durable event streams. Camunda is excellent for explicit process orchestration. The hard part is defining which one decides progress, which one distributes facts, and how duplicate/replayed/out-of-order events are handled.

1. Core mental model

Kafka and Camunda solve different coordination problems.

Kafka:
  durable ordered log per partition
  event distribution
  replay
  fan-out
  consumer group scaling
  integration between services
  temporal decoupling

Camunda:
  explicit process instance
  BPMN execution state
  long-running orchestration
  wait states
  timers
  human tasks
  retries/incidents
  compensation/manual repair

A Kafka topic is not a process instance.

A process instance is not an event stream.

A Kafka consumer offset is not business completion.

A Camunda service task completion is not proof that every downstream event consumer has processed the emitted event.

A senior engineer keeps these boundaries explicit.

2. Why this integration is risky

The dangerous assumption is:

"The process emitted an event, therefore the rest of the system is done."

That is false.

Once a workflow publishes an event to Kafka, downstream consumers may:

• process it later,
• process it more than once,
• process it out of expected business order,
• fail and retry,
• lag behind,
• be replayed from an old offset,
• be running a different schema version,
• ignore the event because of filtering,
• produce their own follow-up events asynchronously.

Another dangerous assumption is:

"Kafka event consumed means we should always start a new process."

That is also false.

The event may be duplicate, replayed, too old, already represented by an active process instance, or invalid for the current entity state.

3. Common integration patterns

3.1 Event starts a process

A Kafka event can be the external trigger that starts a workflow.

Example:

QuoteSubmitted event
  -> Kafka consumer receives event
  -> validates idempotency
  -> starts quote approval process
  -> stores processInstanceKey / processInstanceId against quoteId

Use this when the event represents a meaningful business fact that should start an orchestrated lifecycle.

Good candidates:

• quote submitted,
• order captured,
• fulfillment request accepted,
• fallout created,
• cancellation requested,
• manual review required,
• contract approval requested.

Bad candidates:

• low-level technical telemetry,
• every row update,
• every cache invalidation,
• high-volume events with no explicit process lifecycle,
• events that do not require orchestration.

3.2 Event correlates to an existing process

A Kafka event can advance a waiting process instance.

Example:

Process waits for FulfillmentCompleted message
  -> Kafka event FulfillmentCompleted(orderId=O-123) arrives
  -> consumer maps orderId to correlation key
  -> publishes/correlates Camunda message
  -> process continues

This requires deterministic correlation.

Do not rely on fuzzy matching.

Do not use non-stable fields like display name, mutable account name, or transient UI id.

Prefer stable business identifiers:

• quoteId,
• orderId,
• fulfillmentRequestId,
• contractId,
• caseId,
• businessKey,
• correlationKey.

3.3 Process publishes event

A workflow step may publish a Kafka event as a side effect.

Example:

Approve quote
  -> update quote approval state
  -> publish QuoteApproved event
  -> continue process

This must be idempotent.

If the worker crashes after publishing but before completing the Camunda job, the job can be retried. Without idempotency, the event may be published again.

3.4 Worker consumes Kafka and completes Camunda job

Sometimes a service task delegates work to a worker that internally uses Kafka.

Example:

Camunda job: request-order-decomposition
  -> worker writes command to outbox
  -> outbox publisher emits OrderDecompositionRequested
  -> process waits for OrderDecompositionCompleted message

This pattern avoids pretending the Kafka command completes immediately.

The service task requests work. A later message confirms work completion.

3.5 Kafka connector vs custom worker

Camunda 8 has Kafka connector support in its connector ecosystem, but a connector should not automatically replace a custom worker.

A connector can be reasonable when:

• the integration is simple,
• the payload mapping is straightforward,
• security/secrets are supported by platform conventions,
• retry semantics are acceptable,
• observability is sufficient,
• the side effect is not deeply domain-specific.

A custom worker is often better when:

• idempotency is non-trivial,
• DB transaction + outbox is required,
• schema evolution logic is complex,
• event enrichment requires domain queries,
• failure classification matters,
• fallback/manual repair logic is needed,
• advanced metrics/tracing are required,
• the worker must enforce domain invariants.

4. The boundary rule

Use this rule:

Camunda decides process progress.
Kafka distributes facts and commands.
The domain service enforces business invariants.
PostgreSQL stores durable business truth.

This prevents common architecture drift:

Anti-pattern:
  Kafka topic decides order lifecycle
  Camunda also tracks order lifecycle
  PostgreSQL also tracks order lifecycle
  UI derives status from another projection
  all disagree during failure

A better model:

Business table:
  authoritative order state

Camunda:
  orchestration state and outstanding work

Kafka:
  event distribution and asynchronous integration

Read model:
  derived query/projection state

5. Event starts process: safe design

A safe event-to-process consumer should do more than call startProcessInstance.

5.1 Recommended sequence

Kafka consumer receives event
  -> validate schema and required metadata
  -> derive business key / correlation key
  -> check idempotency/inbox table
  -> check current entity state
  -> decide whether to start/correlate/ignore/park
  -> start process or publish Camunda message
  -> persist mapping/audit
  -> commit consumer-side transaction if applicable
  -> acknowledge offset according to consumer strategy

5.2 Required metadata

At minimum, event metadata should include:

eventId: globally unique event id
eventType: business event name
eventVersion: schema/business version
sourceSystem: producer service
timestamp: event creation time
correlationId: request/trace correlation id
causationId: command/event that caused this event
businessKey: quoteId/orderId/etc
tenantId: if multi-tenant
schemaVersion: explicit payload contract version
traceparent: if distributed tracing is used

Do not make workflow correlation depend on payload shape that can change casually.

5.3 Idempotency key

For starting a process from event:

idempotencyKey = eventType + businessKey + semanticAction

Examples:

QuoteSubmitted:Q-123:start-quote-approval
OrderCaptured:O-456:start-order-validation
CancellationRequested:O-456:start-cancellation-flow

Do not use Kafka offset as the business idempotency key.

Offsets are partition-local transport positions, not domain semantics.

6. Process publishes event: safe design

Publishing to Kafka from a workflow step is a classic side-effect problem.

Bad sequence:

Worker publishes Kafka event
  -> worker completes Camunda job
  -> DB state update happens somewhere else later

This can emit facts that are not yet durable in business tables.

Better sequence with transactional outbox:

Worker activates job
  -> starts PostgreSQL transaction
  -> validates current business state
  -> updates business table
  -> inserts outbox event row with deterministic event id
  -> commits DB transaction
  -> completes Camunda job
  -> separate outbox publisher sends event to Kafka

This gives you a durable event intent even if Kafka is temporarily down.

It also makes duplicate worker execution safer because the outbox row can have a unique constraint.

Example unique constraint:

unique (aggregate_type, aggregate_id, event_type, semantic_version, command_id)

Or:

unique (idempotency_key)

7. Correlation design

Correlation is where many workflow/Kafka integrations fail.

7.1 Business key vs correlation key

A business key identifies the business entity.

orderId = O-123
quoteId = Q-900

A correlation key identifies the waiting process correlation target.

Sometimes they are the same.

Sometimes they are not.

Example:

orderId = O-123
fulfillmentRequestId = FR-777
correlationKey = FR-777

If multiple fulfillment requests can exist for one order, correlating only by orderId may deliver a message to the wrong waiting point.

7.2 Correlation table

For serious systems, maintain a correlation table.

workflow_correlation (
  business_key text not null,
  correlation_key text not null,
  process_instance_key text not null,
  process_definition_key text not null,
  process_version int not null,
  purpose text not null,
  status text not null,
  created_at timestamptz not null,
  closed_at timestamptz null,
  unique (correlation_key, purpose)
)

This helps debug:

• which process is waiting,
• what key it expects,
• whether the message arrived late,
• whether the process already moved on,
• whether the wrong version is active.

7.3 Message TTL

For Camunda 8 message correlation, TTL matters.

If an event arrives before the process reaches the catch event, a message with suitable TTL can wait for correlation.

If TTL is too short, the process may never receive it.

If TTL is too long, stale messages may correlate unexpectedly after process changes.

Treat TTL as business policy, not just technical config.

8. Duplicate events

Kafka consumers must assume duplicate events.

Duplicates can come from:

• producer retry,
• consumer retry,
• offset reset,
• replay,
• outbox publisher retry,
• connector retry,
• deployment restart,
• human replay operation,
• topic compaction assumptions gone wrong.

A workflow consumer should classify duplicates:

Duplicate and already applied:
  acknowledge/ignore safely

Duplicate but previous attempt failed before durable action:
  resume/retry safely

Duplicate with conflicting payload:
  park and create operational alert

Duplicate after process moved beyond wait state:
  record as late/ignored business event

Do not treat all duplicates as harmless.

A duplicate with different payload is a data integrity signal.

9. Out-of-order events

Kafka preserves order only within a partition.

If related events are not keyed consistently, the system can observe:

OrderFulfillmentCompleted
before
OrderFulfillmentStarted

Or:

QuoteApproved v2
before
QuoteSubmitted v1

Mitigation:

• key topic records by stable aggregate id,
• include event version/sequence if domain requires ordering,
• check entity state before acting,
• park impossible transitions,
• use reconciliation for missing predecessor events,
• avoid process logic that assumes global ordering across topics.

In CPQ/order management, ordering matters for:

• quote approval before order capture,
• validation before fulfillment,
• cancellation vs fulfillment completion,
• amendment vs renewal,
• fallout resolution before process completion.

10. Replay impact

Kafka replay is powerful and dangerous.

Replay can be used for:

• rebuilding projections,
• recovering missed integrations,
• reprocessing events after bug fix,
• backfilling new consumers.

But replaying events into workflow command paths can accidentally start or advance processes again.

Separate consumers by intent:

Projection consumer:
  replay-safe
  rebuilds read model

Workflow trigger consumer:
  replay-guarded
  uses idempotency/business state checks

Operational repair consumer:
  manually controlled
  audited
  narrow scope

Never assume a new consumer group is harmless if it starts workflows.

11. Event-driven process vs process-driven event

Two opposite flows are common.

11.1 Event-driven process

External system emits event
  -> workflow starts or advances

Use when external business facts drive the process.

Example:

PaymentReceived
FulfillmentCompleted
PartnerProvisioningFailed
CustomerAcceptedQuote

11.2 Process-driven event

Workflow reaches step
  -> emits command/event to another system

Use when orchestration decides what should happen next.

Example:

RequestCreditCheck
RequestOrderDecomposition
NotifyApprovalRequired
PublishQuoteApproved

Do not mix command and event semantics casually.

A command asks something to happen.

An event says something already happened.

Naming matters.

12. Topic design

Topic design affects workflow correctness.

12.1 Recommended event topic traits

A workflow-relevant topic should have:

• stable naming convention,
• explicit ownership,
• documented event schema,
• partition key strategy,
• retention policy,
• replay policy,
• compatibility rules,
• security/ACL ownership,
• operational dashboard,
• schema registry/governance if used.

12.2 Topic naming examples

quote.events
order.events
fulfillment.events
billing.events
workflow.commands
workflow.events

Avoid ambiguous names:

data
updates
events
camunda-topic
process-topic

12.3 Partition key

For order workflows, usually key by the entity whose event order matters.

key = orderId

For quote workflows:

key = quoteId

For fulfillment subflows:

key = fulfillmentRequestId

If multiple events must be ordered together, key them the same way.

13. Schema governance

Workflow is sensitive to schema drift.

If a field used for correlation changes, process instances can get stuck.

If a field used for routing changes semantics, gateway logic can choose wrong paths.

If a field used for idempotency changes, duplicates can become new commands.

Minimum governance:

• event name is stable,
• event version is explicit,
• compatibility rules are documented,
• required fields are enforced,
• correlation fields are protected,
• deprecated fields have migration window,
• consumers are tested against old and new versions,
• workflow changes are reviewed together with schema changes.

For Camunda workers, do not fetch or write all variables casually. Variable payload discipline matters just as much as event schema discipline.

14. Kafka connector / consumer / worker options

14.1 Camunda 8 Kafka connector

A Kafka connector can simplify producing or consuming Kafka messages from a BPMN process.

Use it carefully for simple integration.

Questions to ask:

• Where are credentials stored?
• How are failures surfaced?
• What retry policy applies?
• How is message key configured?
• How is schema validation done?
• How are duplicate publishes prevented?
• How are connector metrics/logs correlated with process instance?
• Is the connector runtime managed in SaaS, self-managed, or hybrid mode?

14.2 Custom Kafka consumer

Use a custom consumer when workflow triggering requires business-state validation.

Typical responsibilities:

• consume event,
• validate schema,
• enforce idempotency,
• query PostgreSQL,
• update inbox/correlation table,
• call Camunda API,
• emit metrics/traces,
• handle replay mode safely.

14.3 Custom Kafka-producing worker

Use a custom worker when process step must update DB and publish event reliably.

Typical responsibilities:

• activate job,
• validate process variables,
• update business DB,
• insert outbox event,
• complete job,
• let outbox publisher publish to Kafka,
• report failure with correct retry semantics.

15. Camunda 7 integration patterns

In Camunda 7, Kafka integration often appears as:

JavaDelegate publishes/consumes event
External task worker publishes/consumes event
JAX-RS endpoint receives callback and correlates message
Scheduler/consumer starts process

15.1 JavaDelegate caution

A JavaDelegate that directly publishes to Kafka inside the engine transaction can be dangerous.

If the DB transaction rolls back after publish, Kafka has a fact that never committed.

If publish succeeds but delegate throws, retry can publish again.

Use outbox for durable side effects.

15.2 External task worker

External task worker is usually a better place for Kafka integration than embedded delegate when you want decoupling.

But it still needs:

• idempotency,
• lock duration discipline,
• failure reporting,
• outbox/inbox,
• correlation ID propagation,
• duplicate side-effect protection.

16. Camunda 8 integration patterns

In Camunda 8, Kafka integration often appears as:

Zeebe job worker publishes Kafka event
Kafka consumer publishes/correlates Zeebe message
Kafka connector produces/consumes message
Connector runtime integrates with Kafka

Key differences from Camunda 7:

• workers are remote by design,
• jobs can time out and be activated again,
• process state is managed by Zeebe, not the Java app database,
• Operate shows process/incident state,
• connector runtime becomes another operational dependency,
• search/exporter dependency matters for observability.

Do not port Camunda 7 JavaDelegate assumptions into Camunda 8.

17. Java/JAX-RS integration impact

A JAX-RS service may expose endpoints such as:

POST /quotes/{quoteId}/submit
POST /orders/{orderId}/events/fulfillment-completed
GET  /orders/{orderId}/workflow-status
POST /workflow/messages/{messageName}

When Kafka is involved, be clear whether the API:

• writes a command that later publishes to Kafka,
• directly starts a workflow,
• accepts a callback and correlates a workflow message,
• only exposes status from a read model,
• is internal-only for operational repair.

Bad API contract:

POST /orders/{id}/fulfill
200 OK

when fulfillment is actually asynchronous.

Better:

POST /orders/{id}/fulfillment-requests
202 Accepted
Location: /orders/{id}/fulfillment-requests/{requestId}
X-Correlation-Id: ...

Then Kafka/workflow state can progress asynchronously without lying to the caller.

18. PostgreSQL/MyBatis integration impact

Kafka + Camunda almost always needs a durable database pattern.

18.1 Inbox table

Use inbox for consumed events.

workflow_event_inbox (
  event_id text primary key,
  event_type text not null,
  business_key text not null,
  event_version text not null,
  payload jsonb not null,
  status text not null,
  received_at timestamptz not null,
  processed_at timestamptz null,
  error_message text null
)

18.2 Outbox table

Use outbox for emitted events.

workflow_event_outbox (
  outbox_id uuid primary key,
  aggregate_type text not null,
  aggregate_id text not null,
  event_type text not null,
  event_version text not null,
  idempotency_key text not null unique,
  payload jsonb not null,
  status text not null,
  created_at timestamptz not null,
  published_at timestamptz null
)

18.3 MyBatis discipline

With MyBatis/JDBC, avoid hidden transaction behavior.

Checklist:

• mapper method participates in expected transaction,
• update has optimistic lock condition,
• idempotency insert is atomic,
• outbox insert happens in same transaction as business state update,
• no worker completes Camunda job before required DB commit,
• retries hit unique constraints safely,
• mapper does not partially update state without audit.

19. Redis integration impact

Redis may support Kafka/Camunda integration, but should not become the source of truth.

Reasonable uses:

• short-lived rate limit,
• kill switch,
• worker coordination hint,
• dedupe cache for high-volume noise,
• process status cache for UI,
• circuit breaker state.

Dangerous uses:

• only store for idempotency,
• only store for consumed event status,
• only store for correlation mapping,
• only store for command completion,
• lock without expiry discipline,
• cache status used as authoritative truth.

For workflow correctness, durable idempotency belongs in PostgreSQL or another durable store.

20. Observability

Kafka/Camunda integration needs cross-system observability.

Track:

Kafka:
  consumer lag
  consumed event count
  failed event count
  replay mode flag
  dead/parked event count
  partition assignment/rebalance
  producer error rate
  publish latency

Camunda:
  process instances started
  message correlations attempted/succeeded/failed
  incidents
  job retries
  worker latency
  worker failure rate
  stuck wait states

Database:
  inbox pending/failed
  outbox pending/failed
  idempotency conflict count
  optimistic lock conflict count

Business:
  orders awaiting fulfillment event
  quotes awaiting approval event
  fallout pending manual repair
  SLA breach count

Every event should be traceable across:

eventId
correlationId
causationId
businessKey
processInstanceKey/processInstanceId
jobKey/externalTaskId
traceId

21. Security and privacy

Kafka events can leak process-sensitive data.

Review:

• PII in event payload,
• sensitive pricing/contract terms,
• tenant identifiers,
• credentials accidentally embedded in variables/events,
• ACL by topic,
• encryption in transit,
• encryption at rest,
• schema registry access,
• connector secrets,
• event retention duration,
• replay access control,
• logs containing full payload.

Do not publish entire process variable maps to Kafka.

Publish explicit event contracts.

22. Performance and capacity

Workflow/Kafka performance is affected by:

• event volume,
• partition count,
• consumer concurrency,
• worker concurrency,
• message correlation rate,
• process instance start rate,
• variable payload size,
• outbox publisher throughput,
• schema validation cost,
• broker/network latency,
• backpressure from Camunda or Kafka,
• downstream consumer lag.

Do not scale blindly.

If you increase Kafka consumer concurrency, you may also increase process starts, DB writes, Camunda message correlations, and downstream incidents.

Capacity planning must consider the whole chain.

23. Kubernetes, cloud, and on-prem concerns

23.1 Kubernetes

Check:

• consumer pod replica count,
• graceful shutdown,
• partition rebalance behavior,
• readiness probe avoids consuming before ready,
• liveness probe does not kill slow-but-healthy consumer,
• config/secret rotation,
• network policy to Kafka and Camunda,
• resource limits for serialization and batch processing,
• horizontal scaling impact on consumer groups.

23.2 AWS

Check:

• MSK or self-managed Kafka topology,
• IAM/SASL/TLS auth,
• security groups,
• cross-AZ latency,
• CloudWatch metrics,
• Secrets Manager integration,
• EKS pod identity/service account if used.

23.3 Azure

Check:

• Event Hubs Kafka-compatible mode vs Kafka semantics,
• AKS networking,
• managed identity if applicable,
• Key Vault secrets,
• Azure Monitor,
• private endpoints,
• retry behavior under transient network issues.

23.4 On-prem/hybrid

Check:

• firewall rules,
• TLS/internal CA,
• broker reachability,
• offset storage and backup,
• split-brain network failure,
• cross-boundary latency,
• responsibility boundary between platform and app team.

24. Failure modes

24.1 Event consumed but process not started

Possible causes:

• schema validation failed,
• idempotency table thinks event already processed,
• Camunda API unavailable,
• wrong process definition key,
• authorization failure,
• consumer crashed before command,
• process start returned error,
• event parked due to invalid business state.

Debug:

• search by eventId,
• check inbox row,
• check consumer logs,
• check Camunda process instance list,
• check deployment/version,
• check auth/credentials,
• check DB transaction outcome.

24.2 Process waiting but Kafka event arrived

Possible causes:

• wrong correlation key,
• message TTL expired,
• event consumed by wrong consumer,
• event parked as duplicate,
• process waiting for different message name,
• process already moved on,
• event belongs to different fulfillment request,
• tenant mismatch.

Debug:

• compare event business key and process variable,
• inspect waiting message event,
• inspect correlation table,
• check message correlation failure logs,
• check tenant and version.

24.3 Duplicate event created duplicate process

Possible causes:

• no idempotency key,
• idempotency key includes unstable field,
• offset used as identity,
• replay consumer not guarded,
• unique constraint missing,
• process start not checked against active instance.

Repair:

• identify duplicate process instances,
• determine authoritative entity state,
• cancel/terminate duplicate if safe,
• record audit note,
• patch idempotency rule,
• add test.

24.4 Event published but business state not updated

Possible causes:

• direct publish before DB commit,
• outbox not used,
• transaction rollback after publish,
• worker completed job before DB update,
• wrong mapper transaction boundary.

Repair:

• compare event timestamp with DB audit,
• check worker logs,
• check outbox table,
• check process history,
• decide whether compensating event is needed.

24.5 Outbox backlog

Possible causes:

• Kafka unavailable,
• auth failure,
• schema registry unavailable,
• producer serialization failure,
• poison event payload,
• outbox publisher down,
• network partition.

Debug:

• check pending rows by age,
• check publisher logs,
• check Kafka broker health,
• check schema registry,
• check retry/backoff.

25. Production-safe debugging sequence

Use this order during incident triage:

1. Identify business impact.
2. Identify affected business key(s).
3. Find Kafka eventId/correlationId.
4. Check inbox/outbox rows.
5. Check Camunda process instance state.
6. Check waiting activity/message name/timer/job.
7. Check worker/consumer logs by traceId.
8. Check DB business state and audit rows.
9. Check duplicate/replay/out-of-order evidence.
10. Decide retry, correlate, repair, compensate, or ignore.
11. Record manual action with reason.

Do not start by replaying events.

Replay can amplify the incident.

26. Design checklist

Before approving Kafka/Camunda integration, answer:

• What starts the process?
• What advances the process?
• What emits events?
• Which events are commands vs facts?
• What is the business key?
• What is the correlation key?
• What is the idempotency key?
• What happens on duplicate event?
• What happens on out-of-order event?
• What happens on replay?
• What happens when Kafka is down?
• What happens when Camunda is down?
• What happens when DB commit succeeds but job completion fails?
• What happens when event publish succeeds but job completion fails?
• Is outbox/inbox required?
• How is schema compatibility handled?
• How is sensitive data protected?
• How is correlation observable?
• Who owns parked events?
• Who owns workflow incidents?

27. PR review checklist

Review a PR touching Kafka + workflow for:

• stable event contract,
• explicit event metadata,
• deterministic correlation key,
• idempotency guard,
• inbox/outbox usage where needed,
• DB transaction boundary,
• Camunda job completion after durable side effect,
• retry classification,
• duplicate event handling,
• out-of-order handling,
• replay safety,
• schema version compatibility,
• security/PII review,
• metrics/logs/tracing,
• operational repair path,
• tests for duplicate/replay/failure path.

Reject the PR if it only demonstrates the happy path.

Kafka/Camunda integration fails at the boundaries, not in the diagram.

28. Internal verification checklist

Verify inside CSG/team context:

• Which Kafka topics interact with quote/order workflow?
• Which events start process instances?
• Which events correlate to existing process instances?
• Which workflow steps publish Kafka events?
• Are Kafka integrations implemented with Camunda connectors, custom workers, Java delegates, external task workers, or separate consumers?
• What is the canonical business key for quote/order/fulfillment/fallout?
• Is there a correlation table?
• Is there an inbox table?
• Is there an outbox table?
• Are event IDs globally unique?
• Are event schemas governed and versioned?
• What is the replay policy for workflow-triggering consumers?
• Who can trigger replay?
• How are duplicate events detected?
• How are out-of-order events handled?
• How are parked events surfaced operationally?
• How are Kafka failures shown in dashboards?
• Are process instance IDs included in logs/events?
• Are tenant/security boundaries represented in events?
• Are there known incident notes related to Kafka/workflow correlation?

29. Senior engineer heuristics

Use these heuristics:

If an event can be replayed, the workflow trigger must be idempotent.
If an event can arrive late, the process must define late-event behavior.
If an event can arrive out of order, the domain state machine must guard transitions.
If a worker publishes an event, the side effect must be durable and deduplicated.
If a process waits for an event, the correlation key must be stable and observable.
If a connector hides too much reliability logic, use a custom worker.
If nobody owns parked events, the design is incomplete.

Kafka gives you a durable history of things said.

Camunda gives you a durable view of work still expected.

PostgreSQL gives you durable business truth.

Do not make any one of them pretend to be all three.

30. Key takeaways

• Kafka is an event stream, not a workflow engine.
• Camunda is an orchestrator, not a Kafka replacement.
• Event-driven workflow needs explicit correlation.
• Replay safety is mandatory for workflow-triggering consumers.
• Duplicate events are normal, not exceptional.
• Outbox/inbox patterns are usually required for production reliability.
• Worker completion must happen after durable business side effects.
• Schema governance is workflow correctness governance.
• Observability must connect event, process, job, and business entity.
• In CPQ/order management, late or duplicate events can directly affect customer-visible state.

31. References for further study

• Camunda 8 Kafka Connector documentation.
• Camunda 8 connector types documentation.
• Camunda 8 messages and correlation documentation.
• Camunda 8 job worker documentation.
• Existing internal Kafka topic catalog, schema registry, event governance docs, incident notes, and runbooks.