Design your shared objects so they aren’t the thing every transaction must touch; break the hotspot into many small, independent objects (shards) and let each transaction update only its shard, prefer owned objects for per-user state and use dynamic fields or per-key shard objects attached to a tiny shared registry so the registry rarely changes, emit append-only events for history instead of writing large logs on-chain and reconstruct state off-chain, push ownership to the edges (let users mutate their own objects and only aggregate summaries into shared state), use capability-token objects to authorize actions instead of storing per-user mutable records on the shared object, make shared updates commutative and partitionable (deltas, bucketed counters, hash-sharded keys) so order conflicts are minimized, batch many owned-object ops into a single Programmable Transaction Block and touch the shared object once at commit (for example in TypeScript: const tx = new TransactionBlock(); /* modify owned objects / tx.moveCall({ target: "pkg::module::settle", arguments: [ tx.object(shardId), / ... */ ] });), avoid read–modify–write loops on the same key by using monotonic counters, sequence numbers or “last-writer” markers and implement optimistic retries client-side, separate matching from settlement (match in per-pair queues, settle periodically), keep the shared root tiny (store big payloads in child objects or events) and monitor conflict/retry rates so you can add shards or rebalance early; read more: https://docs.sui.io/build/objects.

Use fine-grained sharding of shared state, keep shared objects as lightweight indexes/pointers, and push most data into owned objects. Design so that transactions touch disjoint shared objects whenever possible, and use versioned or append-only patterns to reduce write conflicts.