multi-canister

In Motoko, import the target canister with `import Service "canister:name"` and await its shared methods inside try/catch. In Rust, use `Call::unbounded_wait(canister_id, "method")` from ic-cdk and handle the returned Result to catch rejections.

Split when data exceeds single-canister heap limits, when you need to shard compute across subnets, or when teams need independent upgrade cycles and separate controllers. Simple apps under 1GB of data should stay single-canister to avoid inter-canister call overhead.

Unbounded wait guarantees the caller learns the call outcome but may block upgrades indefinitely if the callee never responds. Bounded wait may return a SYS_UNKNOWN response after a timeout, so non-idempotent calls need a separate endpoint to query the outcome.

Canister request and response payloads are limited to 2MB because cross-subnet messages are packed into 4MB blocks. Requests above 2MB fail synchronously and oversized responses trap, so chunk large transfers into 1MB pieces across multiple calls.

Use the canister factory pattern: call the management canister's create_canister with attached cycles (around 1T), then install_code with the wasm module and init arguments. Track created canisters in stable memory so the mapping survives upgrades.

Code before and after an await runs as separate message executions, so relying on caller context across the await is fragile. Capture `ic_cdk::api::msg_caller()` into a local variable before the await and use that binding afterward.