# TiCDC Deployment Topology

## Question

Which exact changefeed and TiCDC cluster are involved, what independent TiCDC
version/build is running, is the deployment dedicated or shared, and is the
kernel architecture new or classic?

## Enter When

Use only when version, deployment topology, architecture, or target identity is
the customer question. Other TiCDC scenarios acquire this metadata as a
prerequisite but do not add a separate topology scenario.

## First Batch

1. For Cloud, select the ticket's exact business-facing changefeed ID from
   sanitized TiCDC metadata when the cluster type supports it and preserve the
   source-cluster match, state, downstream type, TiCDC cluster status,
   `version`, `deployType`, and explicit control-plane architecture when
   present. For Wetech OP, use the exact routed cluster, supplied changefeed
   identity, and runtime metrics/logs; Cloud Dataflow metadata is not applicable
   and its absence is not a gap.
2. Treat TiCDC version, source TiDB version, deployment type, and kernel
   architecture as independent fields. Never derive one from another.
3. When kernel architecture is still load-bearing and metadata does not state
   it, count one narrow startup marker such as `newarch=true` or
   `TiCDC(new arch) server created`. Absence from an incomplete or narrowly
   retained log query leaves the architecture unknown.

## Decision

`deployType=dedicated` answers dedicated versus shared only. A non-empty
explicit architecture field or an aligned creation marker may answer
new-versus-classic. A version number alone never does. State `unknown` for each
unproven dimension instead of collapsing the identities.

## Strongest Alternative And Stop

Check that another changefeed or source cluster was not selected. Stop after
the requested identity dimensions are either proven or each has one exact
evidence gap. Never restart, patch, convert, or redeploy TiCDC.