docs: clarify "Atomic writing to databases"

co-authored with sword-smith <[email protected]>

docs/src/neptune-core/overview.md

@@ -98,9 +98,9 @@ Blocks are stored on disk and their position on disk is stored in the `block_ind
 
   2. avoid deadlocking others. Always be certain that the global lock will be released in timely fashion. In other words if you have some kind of long running task with an event loop that needs to acquire the global lock, ensure that it gets acquired+released inside the loop rather than outside.
 
-- Atomic writing to databases: `neptune-core` presently writes to the following databases: wallet_db, block_index_db, archival_mutator_set, peer_state. If one of the databases are updated but the other is not, this can leave data in an invalid state. We could fix this by storing all state in a single transactional database.
+- Atomic writing to databases: `neptune-core` presently writes to the following databases: wallet_db, block_index_db, archival_mutator_set, peer_state. If one of the databases are updated but the other is not, this can leave data in an invalid state. We could fix this by storing all state in a single transactional database but that might make the code base less modular.
 
-note: We should also add logic to rebuild the archival state from the `block_index_db` and the blocks stored on disk since it can be derived from the blocks. This functionality could be contained in a separate binary, just like we have a binary for the CLI interface in the form of the RPC client.
+note: We should also add logic to rebuild the archival state from the `block_index_db` and the blocks stored on disk since it can be derived from the blocks. This functionality could be contained in a separate binary or a check could be performed at startup.
 
 ## Tracing
 A structured way of inspecting a program when designing the RPC API, is to use tracing, which is a logger, that is suitable for programs with asynchronous control flow.