# Execute and Write (Continue...)


![left](./student-guide/diagram/05-Write-execution-01-02.png)

------------------------------------------------------------
When the TiKV involved in the modify region receives a write operation, the write process starts. This process is mainly done by the thread pool modules scheduler, raftstore, and apply. The process is as follows:

  - Scheduler module is responsible for coordinating transaction concurrent write conflicts, and writes the received modify operation down. When there is a key value write conflict (such as: lock conflict, version conflict, etc.), the scheduler uses latch to coordinate, and the thread that gets the latch sends the write request to the raftstore module , threads that do not get a latch will wait.
  - After the raftstore module receives a write request, it converts the write request into a Raft log and writes it to rocksdb raft, which is responsible for persisting these raft logs. At the same time, the raftstore module will replica the raft log to rocskdb raft on another TiKV (including the replica written to the region), ready to be written to the other region copy.
  - Since Raft logs are stored in rocksdb raft, the apply module will apply these raft logs to rocksdb kv. At this time, write operations are persisted to rocksdb kv.

In summary, the modify operation is written to the raftstore module through concurrent control by the Scheduler, converted to a raft log, written to the rocksdb raft instance and sent to other rocksdb raft instances in TiKV with replicas for persistence, and finally, by the apply module Persist into the rocksdb kv instance.

For writing RocksDB, refer to “RocksDB - Write” in Lesson 03: TiKV.