I’m examining the production deployment documentation. I have a backend that needs to scale to 1K workflows / s.
I am evaluating the usage of AWS Aurora as the backing store for temporal. However, it can only scale its reads horizontally, not its writes. Therefore, I was wondering if there’s an option for me to configure temporal to perform its reads from the replica node and writes to primary node.
Temporal is a fully consistent service. So reads from a replica that returns stale information are not acceptable.
Would AWS Aurora with multi-master work?
After a quick glance at the multi-master AWS documentation it might work. Please test extensively and update this thread with the results.
In terms of the whole write scalability, I don’t think there’s a way in the Temporal configuration to specify different persistence configuration per shard (I might have missed it, but I couldn’t find it in the configuration reference).
Aurora multi-master provides individual endpoints per DB instance within a cluster, it is the application’s responsibility to provide connection management and map the shards to the corresponding DB instance
This appears to be different from the Cassandra / DynamoDB approach where partitioning is baked into the design of the database to provide horizontal scaling for both reads and writes without the application providing that logic separately outside of the table design and data access patterns.
I see. Then Temporal is not going to work without some additional engineering.