Keep the total where you read it
A denormalised count on the parent turns an aggregate into a single GetItem.
Why
How many replies does a thread have? You could read them all and count, but that read grows without bound as the thread fills up. Instead the count lives on the thread's META item as a denormalised attribute.
So the total is a single GetItem, however long the thread runs. When a reply is posted, ADD bumps replyCount atomically on the server, so two replies at once can never lose each other. The trade is honest: the counter and the reply are two writes, so keeping them exactly in step needs a transaction.
Store the aggregate on the parent and bump it with atomic ADD; reading the total is one GetItem, not a query-and-sum that grows.
Try it. Then change it.
Predict what each request will do. Run it, inspect the response, then change a value in the workbench and try again.
The thread's META item carries replyCount. The total is one item read, no children touched.
The alternative: read every reply and count them. More cost, and it grows with the thread.
ADD increments replyCount atomically on the server. Run it after a reply is posted; concurrent posts can never lose a count.
The thread's META item carries replyCount. The total is one item read, no children touched.
Choose an access pattern above, or build your own request. See what comes back and what it costs.