# Key Features of `TiCDC`

+ At least once delivery for `DDL` and `DML` statements
+ `Sink` support
  + Databases compatible with `MySQL` protocol
    + Keep the order of single-row updates
    + Ensures the atomicity of single-table transactions by default
    + Does not keep the transactions order
    + Does not ensure the atomicity of cross-table transactions
  + `Kafka` based on the `TiCDC Open Protocol`
    + Flexible partition keys support
    + Flexible consistency level support

---------------------------------------------------------------------
`TiCDC` sink component supports replicating data to the following downstream platforms:
- Databases compatible with `MySQL` protocol. The sink component provides the final consistency support.
- `Kafka` based on the `TiCDC Open Protocol`. The sink component ensures the row-level order, final consistency or strict transactional consistency.

Replication order
- For all `DDL` or `DML` statements, `TiCDC` outputs them at least once.
- When the `TiKV` or `TiCDC` cluster encounters failure, `TiCDC` might send the same `DDL/DML` statement repeatedly. For duplicated `DDL/DML` statements:
  - `MySQL` sink can execute `DDL` statements repeatedly. For `DDL` statements that can be executed repeatedly in the downstream, such as truncate table, the statement is executed successfully. For those that cannot be executed repeatedly, such as create table, the execution fails, and `TiCDC` ignores the error and continues the replication.
  - `Kafka` sink sends messages repeatedly, but the duplicate messages do not affect the constraints of `Resolved Ts`. Users can filter the duplicated messages from `Kafka` consumers.

Replication consistency
- `MySQL` sink
  - `TiCDC` does not split single-table transactions and ensures the atomicity of single-table transactions.
  - `TiCDC` does not ensure that the execution order of downstream transactions is the same as that of upstream transactions.
  - `TiCDC` splits cross-table transactions in the unit of table and does not ensure the atomicity of cross-table transactions.
  - `TiCDC` ensures that the order of single-row updates is consistent with that in the upstream.
- `Kafka` sink
  - `TiCDC` provides different strategies for data distribution. You can distribute data to different `Kafka` partitions based on the table, primary key, or timestamp.
  - For different distribution strategies, the different consumer implementations can achieve different levels of consistency, including row-level consistency, eventual consistency, or cross-table transactional consistency.
  - `TiCDC` does not have an implementation of `Kafka` consumers, but only provides `TiCDC Open Protocol`. You can implement the `Kafka` consumer according to this protocol.

For `MySQL` sink, since `v6.1.1`, you can use the sink `uri` parameter `transaction-atomicity` to control whether to split single-table transactions. Splitting single-table transactions can greatly reduce the latency and memory consumption of replicating large transactions.