Sharding-by-key: split “global” state into many shared shards (e.g., per-pool, per-price-level, per-bucket) so unrelated txs don’t collide.

Child objects over big maps: store data in many small child objects instead of one giant shared table; mutate children, not the parent.

Read-only where possible: use &T over &mut T on shared objects to avoid global ordering.

Deterministic IDs: avoid global counters; derive IDs from tx_context or hashes.

Batch locally, settle once: do work on owned objects, then do a minimal shared-object update.

Conflict handling: expect version bumps; catch/retry failed txs.

Profile contention: simulate mixed workloads and measure shared-object hotspots early.

custom – more flexible, you can implement custom checks for upgrades.

Upgrade Flow The upgrade process is two-step:

Prepare Upgrade → Validate the new version against the chosen policy.

by user or use-case

Minimize writes to shared objects

Use read-only patterns when possible

Leverage capability objects for

To avoid shared object conflicts in Sui dApps:

Use owned objects instead of shared ones

Partition state by user or use-case

Minimize writes to shared objects

Use read-only patterns when possible

Leverage capability objects for delegation

Test for conflicts using simulations or local testnet

Simple design = better parallelism and fewer conflicts.

You avoid conflicts in shared object usage on Sui by designing your dApp so that most transactions work with owned objects rather than shared ones, since owned objects can execute in parallel without contention. When you do need shared objects, structure them to minimize writes—store global settings in a shared object but keep user-specific data in owned objects. Break large shared states into smaller composable objects so different users can interact with separate parts independently. You can also use events instead of repeatedly updating shared objects to record activity off-chain. Finally, always design functions with clear access patterns and version checks, so conflicts are detected early and retried safely.

Read more here: Sui Object Model.

You avoid conflicts in shared object usage on Sui by carefully structuring how your dApp handles state. Since shared objects can be accessed by multiple users at once, you need to design your logic so that operations don’t block or overwrite each other unnecessarily. The best practice is to minimize the size and frequency of shared object updates, break down state into smaller independent objects when possible, and use immutable or owned objects for operations that don’t require shared access. This reduces contention and improves parallel execution.