# Writes Data - Cont'd

![`smart`](ExecuteandWrite02_aa_005_20220512.png)

-----------------------------------------------------------
When a TiKV server involved in the modified Region receives a write operation, it starts the write process. This process is mainly composed of the thread pool module `Scheduler`, Raftstore and Apply. The process is as follows:

1. The `Scheduler` module is responsible for coordinating transaction concurrent writes and pushing down received modification operations. When there is a key-value write conflict (e.g. lock conflict, version conflict, etc.), `Scheduler` uses latch to coordinate, and the thread that obtains the latch will send the write request to the Raftstore module, while the thread that does not obtain the latch will be in a waiting state.

2. After the Raftstore module receives the write request, it will transform the write request into a Raft Log and write it into RocksDB Raft, which is responsible for persisting these Raft Logs. At the same time, the Raftstore module will replicate the Raft Logs to the RocksDB Raft on other TiKV (including the replicas of the written Region), preparing to write to other Region replicas.

3. Due to the fact that RocksDB Raft stores the Raft Log, the Apply module will apply these Raft Logs to RocksDB KV, at which point, the write operations are persisted to RocksDB KV.

In summary, the modification operation is controlled by `Scheduler` and written to the Raftstore module, transformed into Raft Log and written to the RocksDB Raft instance in other TiKV servers containing replicas, and finally persisted to the RocksDB KV instance by the Apply module.