<p>Simple explanation: <strong>you can't update the same key several times inside the same block</strong>: if you send several transactions updating the same key and all transactions get processed in the same block, only one of them (I think the first one) will be processed and the other transactions will be rejected. That's why in your case, when you send txns very close in time, only one is processed, and if you add a sleep between calls, both get processed correctly (the sleep must be equal or higher than your block time). There are several ways to handle this situation, one could be the use of queues, and of course design your internal architecture in a way you can minimize this kind of issues.</p>

<p><strong>Update:</strong></p>

<blockquote>
  <p>Is it not possible to set the block size to max 1 transactions?</p>
</blockquote>

<p>Can't answer with confidence without further reading/investigation. Not sure about the implications in terms of stability and performance of the network using such a configuration. There's an interesting paper about performance and optimization of HLF written a year ago (may 2018) here <a href="https://arxiv.org/pdf/1805.11390.pdf" rel="nofollow noreferrer">https://arxiv.org/pdf/1805.11390.pdf</a> which may be of help. Maybe this weekend I can get some time to run my own tests. Let me know if you find something else about this topic because it seems interesting to me, though I smell it's not going to work fine because the network has an inherent latency itself so you can't reach consensus in near to 0 time.</p>

<blockquote>
  <p>Is this same with Sawtooth?</p>
</blockquote>

<p>Don't have experience with that platform, but I think the same idea applies: a blockchain is a network that needs time to reach consensus about a fact, so trying to reach that consensus in lesser time than the inherent latency of the network plus the time of executing the consensus algorithms, won't work in any case.</p>
Hyperledger Fabric -- if two update happening nearly same time, the second is dropped
<p>I am just trying to learn the Hyperledger Fabric and I made a little test:</p>

<pre><code>type Valami struct {
        ObjectType string `json:"docType" binding:"required"`
        Value string `json:"value" binding:"required"`
        ID string  `json:"id" binding:"required"`

}

func (t *SimpleChaincode)  test(stub shim.ChaincodeStubInterface)  pb.Response {
        id := "104"
        asbytes, err := stub.GetState(id) //get the marble from chaincode state
        obj := &amp;Valami{}
        if err != nil {
                return shim.Error("Failed to get state ")
        } else if asbytes == nil {
                fmt.Println("not found")
                objtype := "test"
                obj = &amp;Valami{objtype, "", id}

        } else {
                fmt.Println("found")
                err = json.Unmarshal(asbytes, obj)
                if err != nil {
                        return shim.Error("Can not process to a JSON type!")
                }
        }

        now := time.Now()
        value := now.String()
        fmt.Println("value: "+value)
        obj.Value = value


         // update
        JSONasBytes, err := json.Marshal(obj)
        if err != nil {
                return shim.Error("Can not update the " + obj.ID + ". Reason: "+err.Error())
        }
        // save in state
        err = stub.PutState(obj.ID, JSONasBytes)
        if err != nil {
                return shim.Error("Can not save "+ obj.ID + ". Reason: "+err.Error())
        }
        return shim.Success([]byte("value: "+obj.Value))
}
</code></pre>

<p>After I commit this twice quickly after each other:</p>

<pre><code>docker exec -e CORE_PEER_LOCALMSPID=Org1MSP -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp cli peer chaincode invoke -o orderer.example.com:7050 -C mychannel -n mur2 -c '{"Args":["test"  ]}'
  docker exec -e CORE_PEER_LOCALMSPID=Org1MSP -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp cli peer chaincode invoke -o orderer.example.com:7050 -C mychannel -n mur2 -c '{"Args":["test"  ]}'
</code></pre>

<p>The return: </p>

<pre><code>2019-03-13 09:33:05.297 UTC [chaincodeCmd] chaincodeInvokeOrQuery -&gt; INFO 001 Chaincode invoke successful. result: status:200 payload:"value: 2019-03-13 09:33:05.292254505 +0000 UTC m=+391.210396576"
2019-03-13 09:33:05.776 UTC [chaincodeCmd] chaincodeInvokeOrQuery -&gt; INFO 001 Chaincode invoke successful. result: status:200 payload:"value: 2019-03-13 09:33:05.770792084 +0000 UTC m=+391.688934322"
</code></pre>

<p>So it looks like everything fine. However when I check the value: </p>

<pre><code>"{\"docType\":\"test\",\"id\":\"104\",\"value\":\"2019-03-13 09:33:05.292254505 +0000 UTC m=+391.210396576\"}"
</code></pre>

<p>So actually the second commit does not come across.  If I put a sleep between the two commits, they work.  So I guess the first one is not finishing before the second start and some reason the second dropped.  I have not expected this, because it could happen any time on a network.  Could somebody explain for me what happening in the background and how we can handle this kind of situation?</p>