# TiCDC Architecture, Version, And Deployment Topology Boundaries

Apply this topic only to TiCDC/changefeed questions where version, architecture,
deployment, or architecture-specific monitoring affects the answer.

## Independent identities

- TiCDC has its own version/build. Never report the source TiDB cluster version
  as the TiCDC version or infer one from the other.
- Dedicated versus shared TiCDC deployment is a topology fact. It does not prove
  whether the TiCDC kernel uses the new or classic architecture.
- A Dataflow/Dataflow-NG or rep-cdc control-plane identity is not itself proof
  of the TiCDC kernel architecture.
- The strongest direct proof is an explicit architecture field or an aligned
  startup/deployment marker such as `newarch=true`.
- When direct proof is unavailable, an exact-target, exact-window runtime chain
  can still confirm that the changefeed is executing through the new
  architecture. Require coherent activity across multiple new-architecture-only
  stages: Maintainer plus dispatcher and Event Service, with Event Store or Log
  Service where that stage is observable. Metric-name existence, one active
  series, or unrelated samples are not a runtime chain.
- A version number, `arch=dedicated`, `deploy_type`, dedicated topology,
  Dataflow identity, or one owner/dispatcher metric is insufficient by itself.
- A classic compatibility metric is counterevidence to classify, not an
  automatic veto of a complete aligned new-architecture runtime chain.
- When runtime-chain evidence is used, say that the exact changefeed is
  confirmed to be executing through the new-architecture runtime path and
  disclose that the explicit control-plane architecture field or startup marker
  was absent. Do not claim that metadata directly identified the architecture.
  When neither direct proof nor a complete runtime chain is available, say the
  kernel architecture is unknown.

<!-- report-judge-guidance:start -->
For a TiCDC architecture claim, evaluate the evidence in three tiers. An
explicit control-plane architecture field or an aligned startup/deployment
marker is direct proof. If direct proof is absent, coherent exact-changefeed,
exact-window activity across Maintainer, dispatcher, Event Service, and where
observable Event Store or Log Service can confirm execution through the new
architecture runtime path, provided the answer discloses the absent direct
field/marker. TiCDC version, `arch=dedicated`, `deploy_type`, topology,
Dataflow identity, metric-family existence, or one owner/dispatcher series is
insufficient alone. A classic compatibility metric is counterevidence, not an
automatic veto of a complete aligned new-architecture chain. Do not penalize a
bounded runtime-path conclusion merely because no explicit metadata field
exists; do penalize wording that claims direct metadata proof when only the
runtime chain was observed.
<!-- report-judge-guidance:end -->

## Architecture behavior

The new architecture separates the stateful Log Service/Event Service/Event
Store path from stateless scheduling and downstream adapter work, and uses an
event-driven processing model. Classic and new TiCDC nodes cannot be mixed in
one TiCDC cluster. Treat conversion, patching, pause/resume, and deployment as
human-owned operations; a read-only diagnosis never performs them.

The new architecture requires an upstream TiDB cluster at v7.5.0 or later, but
that compatibility floor still does not make the TiDB and TiCDC versions the
same fact.

## Progress diagnosis

Compare same-changefeed ResolvedTS and CheckpointTS before drilling down:

- rising ResolvedTS lag together with CheckpointTS lag points upstream of
  resolved progress, such as TiKV CDC scan, puller, Event Service, Event Store,
  or dispatcher processing;
- normal ResolvedTS lag with rising CheckpointTS lag points downstream of
  resolved progress, such as DDL/barrier handling, sink queue/write, Kafka
  acknowledgement/retry, cloud-storage spool, or downstream capacity.

Use the architecture-specific dashboard and metric families. Do not combine a
classic owner/processor series with a new-architecture maintainer/dispatcher or
Event Service series as though they were one measurement.

For customer-citable monitoring semantics, use the current official TiCDC
monitoring documentation:
https://docs.pingcap.com/tidb/stable/monitor-ticdc/