Great article!

I would advice to reuse the client, it will save you a lot of time.

In REST:

ClassMethod init()
{
    If '$data(%JDBCGateway) {
            Set %JDBCGateway("client") = ##class(%SYS.Python).Import("boto3").client("dynamodb")
            Set %JDBCGateway("table") = ..getTable("us-east-2", "mytable")
  }
}

ClassMethod getTable(region, tablename) As %SYS.Python [ Language = python ]
{
    import json
    import boto3
    dynamo = boto3.resource("dynamodb", region_name=region)
    return dynamo.Table(tablename)
}

ClassMethod writepy(table, pk, sk, msg) [ Language = python ]
{
    message_record = {
        "PK": pk,
        "SK": sk,
        "msg": msg
    }
    table.put_item(Item=message_record)
}

And call writepy, passing %JDBCGateway("table")  (or %JDBCGateway("client")).

In interoperability Business Hosts it can look like this:

Class App.BS Extends Ens.BusinessService
{

Parameter ADAPTER = "Ens.InboundAdapter";
Property Adapter As Ens.InboundAdapter;
Property Table As %SYS.Python;
Method OnInit() As %Status
{
    Set ..Table = ##class(App.REST).getTable("region", "table")
    Quit $$$OK
}

}

Also when you're using resource Table instead of client you can use normal JSON and not DynamoDB JSON which makes code more readable and you can also use Dynamic Objects to serialize to json / in python parse it from json to dict and call update.

what is the reason of having nested transactions inside the Worker method?

The idea is to check that TCOMMIT works, for additional safety, but yes, inner pair of TSTART/TCOMMIT can be taken out.

And how can you distribute single ("root") transaction execution and control among several processes?

No problems with that, transaction iterates over history data, so it's possible to chunk it.

another approach

Thank you. Locking situation would be better with this approach.