With the goal of making the process layout on each AZ more symmetric? IIRC, AZ to AZ communication has a slightly higher price and latency, so my point still somewhat stands.
If the concern is about reserving two resolution processes in each AZ when you’d only ever use 1/3 of that, then I don’t have a great answer to that. You can run stateless processes instead of resolution, with likely no meaningful change to the resulting cluster’s behavior as long as you supply enough stateless processes so that proxies and resolvers don’t share. You can also technically not run stateless or resolution class processes in one of the three AZs, because if you lose one AZ you’d still be assured to have one left that can run your transaction subsystem.
… we’ve also totally talked through Ricky’s deployment before, and apparently all the details had left my head. Maybe I should go change my logo to a goldfish…
That’s what I’ve been thinking through now, and I haven’t come to a conclusion. My mental model of triple is that it should only care about zoneId, so I’m assuming that this was accidentally introduced when adding three_datacenter or multi-region, and they assumed that you wouldn’t specify dcId for a cluster that’s triple replicated. On the other hand, I feel like triple sort of did the “right” thing here, in that it “helped” you avoid a potentially sub-optimal database configuration. My idiomatic and pragmatic sides are at war.