# Writes Execution
__*Scheduler*__
__*Raftstore*__

![left](./student-guide/diagram/ExecuteandWrite02_aa_002_20220512.png)

------------------------------------------------------------
When TiKV involving 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:

1. The Scheduler module is responsible for coordinating transaction concurrently with write conflicts, and writes the received modify operations downwards. 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 obtained the latch will send the write request to the raftstore module. Threads that do not get a latch will be in a waiting state.

2. After the Raftstore module receives the write request, 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 other TiKV (containing the replica written to the region), and prepare it to be written to the other region copy.

3. Since rocksdb raft stores Raft logs, 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 raft log, written to rocksdb raft instance and sent to other rocksdb raft instances in TiKV with replicas for persistence, and finally, by the apply module Persist to a rocksdb kv instance.

For details on writing RocksDB, refer to "RocksDB - Write" in Lesson 03: TiKV.