At a high level writes are or can be fire or forget since all the information is there. You mail a letter, once in the mailbox you are done it is delivered when it gets delivered. Some designs have feedback but usually the feedback is at the nearest level, it has left the processor into the memory controller, just like I put it in the mailbox, I saw myself do it, done, I can go do something else. Reads you have to wait, like the dark ages of mail. You mail a letter with your order and your check then you wait until the product arrives. A full round trip. The task is not done until the response arrives.
With writes depending on the architecture, the overall system architecture, there are and may be a number of write buffers along the way to the ultimate target memory. dram for example. the processor itself the bus controller on the chip side of the processor bus, each layer of cache, the dram controller, can all have buffers that can store some number of writes. Each of these buffers is fixed in size and when full will back pressure the bus that feeds it so it is like my mailbox is packed with outgoing mail I cant squeeze another letter in I will have to just hold on to the letter until the mailbox has been emptied by the postal person. For each bus and buffer this can happen and the back pressure can go back all the way to the processor or can be herky/jerky. In general that is the only way you know there is something going on with the write system, when you get stalled, but usually your code does not know that it is stalled on the execution of a write instruction.
There are certain times where you need to know the write happened, particularly with bus controllers or peripherals, if you want to change say some memory mapping of a bus controller there is a write path from the processor to the bus controller itself then there are read/write paths along that bus which may not be routed the same way through the system. So you may have to do a write to the bus controller, then read back the register, THEN you can use the bus that is being controlled. The read requires a round trip, you can usually discard the contents of the read the purpose of the read is that for most systems or lets say this system in particular, there is also a command buffer, so reads and writes and any other bus commands that can be on this bus will go linearly into a buffer and get executed in the order they arrive, so if you do a write then a read, the write happens first, causing the bus controller to change how the bus works, the read then will happen after the write when it gets there, but your processor/process is stalled until the read completes, by the time the read completion gets back to the processor core the write is complete the bus is ready to use. there are system architectures where reads can pass writes and that is a whole other deal. But it is not uncommon to do a read operation after a write operation to have an indication to know that a write has completed. Otherwise you actually do not and will not know, the whole architecture around the processor and the layers of busses are designed such that you can fire and forget writes until/unless they back pressure to the point that the processor stalls on a write.
the busses themselves, today you will see things like write address bus, write data bus, read address bus, read data bus, both have handshakes (read and write) you start on the address bus i have this thing I want to write, here is the address. Then the controller on the other side, WHEN IT HAS BUFFERS SPACE AND CAN PROCESS YOUR COMMAND, comes back on an ack bus and says I see your write I am ready for your data. then you write the data on the data bus using an ID that was either created by you on the write address or an ID that came from the controller. then you get an ack back on the write data bus. this also allows for many transactions to be in flight at the same time (and for some architectures things can pass each other and get out of order depending on how far each item goes). The read would work the same way from a handshake perspective the real difference is the write data ack only has to go maybe to the controller or a first level cache and then get an ack. Where a read data ack has to go all the way to the target and come back with the data. so the data bus handshake TIME is longer for a read.
There are other architectures, some folks may say it has to do with the generation/evolution of when your thing was created, but that is not true there are many open and purchased/closed designs that use the good old read/write address/data chip select type bus and it is all based on timing of clocks and maybe a wait control signal to hold off the master to allow reads or writes to happen, you will see these on even the most cutting edge technology peripherals as well as a number of other designs. Once you get into a memory target/subsystem though you still will likely have writes buffered and reads have to take a round trip (although into a cache hopefully making that particular trip take less time than a miss).
reality is it is what the designers decided to do for that system, you will see the good old fashioned put the address and read/write line request on the bus and count X clocks and expect an answer on a specific clock. All the way to multiple busses with handshakes and ids and other parameters working multiple transactions at a time, even out of order. And everything in between.