Apply suggestions from review

Author: kbatuigas

modules/develop/pages/transactions.adoc

@@ -30,11 +30,11 @@ By default, the `enable_transactions` cluster configuration property is set to t
 * xref:develop:transactions.adoc#atomic-publishing-of-multiple-messages[Atomic (all or nothing) publishing of multiple messages]
 * xref:develop:transactions.adoc#exactly-once-stream-processing[Exactly-once stream processing]
 
-When you use transactions, you must set the `transactional.id` property in the producer configuration. This property uniquely identifies the producer and enables reliable semantics across multiple producer sessions. It ensures that all transactions issued by a given producer are completed before any new transactions are started.
+When you use transactions, you must set the https://kafka.apache.org/documentation/#producerconfigs_transactional.id[`transactional.id`^] property in the producer configuration. This property uniquely identifies the producer and enables reliable semantics across multiple producer sessions. It ensures that all transactions issued by a given producer are completed before any new transactions are started.
 
 === Atomic publishing of multiple messages
 
-A banking IT system with an event-sourcing microservice architecture illustrates the necessity for transactions. A bank has multiple branches, and each branch is an independent microservice that manages its own non-intersecting set of accounts. Each branch keeps its own ledger, represented as a Redpanda partition. When a branch (microservice) starts, it replays its ledger to reconstruct the actual state.
+A banking IT system with an event-sourcing microservice architecture illustrates why transactions are necessary. In this system, each bank branch is implemented as an independent microservice that manages its own distinct set of accounts. Every branch maintains its own transaction history, stored as a Redpanda partition. When a branch starts, it replays the transaction history to reconstruct its current state.
 
 Financial transactions such as money transfers require the following guarantees:
 
@@ -274,7 +274,7 @@ To help avoid common pitfalls and optimize performance, consider the following w
 ifndef::env-cloud[]
 * When running transactional workloads from clients, tune xref:reference:cluster-properties#max_transactions_per_coordinator[`max_transactions_per_coordinator`] to the number of active transactions that you expect your clients to run at any given time (if your client transaction IDs are not reused). 
 +
-The total number of transactions in the cluster at any one time is `max_transactions_per_coordinator * transaction_coordinator_partitions` (`transaction_coordinator_partitions` default is 50). When the threshold is exceeded, Redpanda terminates old sessions. If an idle producer corresponding to the terminated session wakes up and produces, its batches are rejected with the message `invalid producer epoch` or `invalid_producer_id_mapping`, depending on where it is in the transaction execution phase.
+The total number of transactions allowed in the cluster at any time is determined by `max_transactions_per_coordinator * transaction_coordinator_partitions` (default is 50 partitions). When the limit is exceeded, Redpanda terminates old sessions. If an idle producer corresponding to a terminated session becomes active and tries to produces again, Redpanda rejects its batches with an `invalid producer epoch` or `invalid_producer_id_mapping` error, depending on where it is in the transaction execution phase.
 +
 Be aware that if you keep the `transaction_coordinator_partitions` at the default of 50 and your clients create a new ID for every transaction, the total continues to accumulate, which bloats memory.
 * Transactional metadata is stored in the internal topic `kafka_internal/tx`. Over time, this topic can consume disk space. You can manage its disk usage by tuning the `transaction_coordinator_delete_retention_ms` and `transactional_id_expiration_ms` cluster properties.