multi-canister

name	multi-canister
description	Design and deploy multi-canister dapps. Covers inter-canister calls, canister factory pattern, async messaging pitfalls, bounded vs unbounded wait, and 2MB payload limits. Use when splitting an app across canisters, making inter-canister or cross-canister calls, or designing canister-to-canister communication. Do NOT use for single-canister apps.
license	Apache-2.0
compatibility	icp-cli >= 0.2.2
metadata	{"title":"Multi-Canister Architecture","category":"Core"}

Multi-Canister Architecture

What This Is

Splitting an IC application across multiple canisters for scaling, separation of concerns, or independent upgrade cycles. Each canister has its own state, cycle balance, and upgrade path. Canisters communicate via async inter-canister calls.

Prerequisites

• For Motoko: mops package manager, core = "2.1.0" in mops.toml — Runtime.envVar, used below to discover a sibling canister's ID, was added in motoko-core 2.1.0
• For Rust: ic-cdk >= 0.19, candid, serde, ic-stable-structures

How It Works

A caller canister makes a call to a callee canister: the method name, arguments (payload) and attached cycles are packed into a canister request message, which is delivered to the callee after the caller blocks on await; the callee executes the request and produces a response; this is packed into a canister response message and delivered to the caller; the caller awakes fron the await and continues execution (executes the canister response message). The system may produce a reject response message if e.g. the callee is not found or some resource limit was reached.

Calls may be unbounded wait (caller MUST wait until the callee produces a response) or bounded wait (caller MAY get a SYS_UNKNOWN response instead of the actual response after the call timeout expires or if the subnet runs low on resources). Request delivery is best-effort: the system may decide to reject any request instead of delivering it. Unbounded wait response (including reject response) delivery is guaranteed: the caller will always learn the outcome of the call. Bounded wait response delivery is best-effort: the caller may receive a system-generated SYS_UNKNOWN reject response (unknown outcome) instead of the actual response if the call timed out or some system resource was exhausted, whether or not the request was delivered to the callee.

When to Use Multi-Canister

Reason	Threshold
Storage limits	Each canister: up to hundreds of GB stable memory + 4GB heap. If your data could exceed heap limits or benefit from partitioning, split storage across canisters.
Scalable compute	Canisters are single-threaded actors. Sharding load across multiple canisters, potentially across multiple subnets, can significantly improve throughput.
Separation of concerns	Auth service, content service, payment service as independent units.
Independent upgrades	Upgrade the payments canister without touching the user canister.
Access control	Different controllers for different canisters (e.g., DAO controls one, team controls another).

When NOT to use: Simple apps with <1GB data. Single-canister is simpler, faster, and avoids inter-canister call overhead. Do not over-architect.

Issues that May Cause Functional Bugs

For building a multi-canister application, take the perspective of an experienced senior software engineer and carefully read the following issues that may cause subtle functional bugs. Meticulously avoid bugs that could be caused by these issues.

1. Request and response payloads are limited to 2 MB. Because any canister call may be required to cross subnet boundaries; and cross-subnet (or XNet) messages (the request and response corresponding to each canister call) are inducted in (packaged into) 4 MB blocks; canister request and response payloads are limited to 2 MB. A call with a request payload above 2 MB will fail synchronously; and a response with a payload above 2 MB will trap. Chunk larger payloads into 1 MB chunks (to allow for any encoding overhead) and deliver them over multiple calls (e.g. chunked uploads or byte range queries).

2. Update methods that make calls are NOT executed atomically. When an update method makes a call, the code before the await is one atomic message execution (i.e. the ingress message or canister request that invoked the update method); and the code after the await is a separate atomic message execution (the response to the call). In particular, if the update method traps after the await, any mutations before the await have already been persisted; and any mutations after the await will be rolled back. Design for eventual consistency or use a saga pattern. If more context on this is needed, you can optionally refer to properties of message executions on ICP.

3. Use idempotent APIs. Or provide a separate endpoint to query the outcome of a non-idempotent call. If a call to a non-idempotent API times out, there must be another way for the caller to learn the outcome of the call (e.g. by attaching a unique ID to the original call and querying for the outcome of the call with that unique ID). Without a way to learn the outcome, when the caller receives a SYS_UNKNOWN response it may be unable to decide whether to continue, retry the call or abort.

4. Calls across subnet boundaries are slower than calls on the same subnet. Under light subnet load, a call to a canister on the same subnet may complete and its response may be processed by the caller within a single round. The call latency only depends on how frequently the caller and callee are scheduled (which may be multiple times per round). A cross canister call requires 2-3 rounds either way (request delivery and response delivery), plus scheduler latency.

5. Calls across subnet boundaries have relatively low bandwidth. Cross-subnet (or XNet) messages are inducted in (packaged into) 4 MB blocks once per round, along with any ingress messages and other XNet messages. Expect multiple MBs of messages to take multiple rounds to deliver, on top of the XNet latency. (Subnet-local messages are routed within the subnet, so they don't suffer from this bandwidth limitation).

6. Defensive practice: bind msg_caller() before .await in Rust. The current ic-cdk executor preserves caller across .await points via protected tasks, but capturing it early guards against future executor changes. Motoko is safe: public shared ({ caller }) func captures caller as an immutable binding at function entry.

   // Recommended (Rust) — capture caller before await:
   #[update]
   async fn do_thing() {
       let original_caller = ic_cdk::api::msg_caller(); // Defensive: capture before await
       let _ = some_canister_call().await;
       let who = original_caller; // Safe
   }
   

7. Not handling rejected calls. Inter-canister calls can fail (callee trapped, out of cycles, canister stopped). In Motoko use try/catch. In Rust, handle the Result from ic_cdk::call. Unhandled rejections trap your canister.

8. Canister factory without enough cycles. Creating a canister requires cycles. The management canister charges for creation and the initial cycle balance. If you do not attach enough cycles, creation fails.

9. Not setting up #[init] and #[post_upgrade] in Rust. Without a post_upgrade handler, canister upgrades may behave unexpectedly. Always define both.

Issues that May Cause Security Bugs

Take the perspective of an experienced senior security engineer and carefully read the following issues that may cause risky security issues. Meticulously avoid such security bugs.

1. Avoid reentrancy issues. The fact that calls are not atomic can cause reentrancy bugs such as double-spending vulnerabilities, see also "Update methods that make calls are NOT executed atomically" above. Avoid such issues, e.g. by employing locking patterns. If more context is needed, you can optionally refer to the security best practices or the paper.

2. Securely handle traps in callbacks. A trap (a panic in Rust) in a callback causes the callback to not apply any state changes. For example, if a trap can be caused by a malicious entity, it could mean that security critical actions like debiting an account in a DeFi context can be skipped, leading to critical issues like double-spending. To avoid this, avoid traps in callbacks that could cause such bugs, consider using call_on_cleanup, and use "journaling". If more context is needed, optionally consider this security best practice.

3. Unbounded wait calls may prevent canister upgrades, indefinitely. Unbounded wait calls may take arbitrarily long to complete: a malicious or incorrect callee may spin indefinitely without producing a response. Canisters cannot be stopped while awaiting responses to outstanding calls. Bounded wait calls avoid this issue by making sure that calls complete in a bounded time, independent of whether the callee responded or not. If more context is needed, optionally consider this security best practice.

4. canister_inspect_message is not called for inter-canister calls. It only runs for ingress messages (from external users). Do not rely on it for access control between canisters. Use explicit principal checks instead. If more context is needed, optionally consider this security best practice.

Mistakes That Break Your Build

1. Trying to order deployment with a dependencies field. icp.yaml has a dependencies field but it is not used to order the deployment — icp-cli builds canisters in parallel, and icp deploy injects every canister's ID into every canister as a PUBLIC_CANISTER_ID:<canister-name> environment variable, so a canister can discover a sibling's ID at runtime regardless of deploy order. Read it with Runtime.envVar<system>("PUBLIC_CANISTER_ID:user_service") in Motoko (motoko-core >= 2.1.0) or ic_cdk::api::env_var_value("PUBLIC_CANISTER_ID:user_service") in Rust. See the icp-cli skill's Canister Environment Variables section.

2. Forgetting to generate type declarations for each backend canister. Use language-specific tooling (e.g., didc for Candid bindings) to generate declarations for each backend canister individually.

3. Shared types diverging between canisters. If canister A expects { id: Nat; name: Text } and canister B sends { id: Nat; title: Text }, the call silently fails or traps. Use a shared types module imported by both canisters.

Implementation

Project Structure

my-project/
  icp.yaml
  mops.toml
  src/
    shared/
      Types.mo          # Shared type definitions
    user_service/
      main.mo           # User canister
    content_service/
      main.mo           # Content canister
    frontend/
      ...               # Frontend assets

icp.yaml

canisters:
  - name: user_service
    recipe:
      type: "@dfinity/motoko@v5.0.0"
  - name: content_service
    recipe:
      type: "@dfinity/motoko@v5.0.0"

mops.toml

The @dfinity/motoko@v5+ recipe compiles via mops build <canister-name>, so each canister's main lives in mops.toml, not in recipe.configuration in icp.yaml. Every canister name in icp.yaml must have an exactly matching [canisters.<name>] key here, or the build fails with No Motoko canisters found in mops.toml configuration.

[toolchain]
moc = "1.9.0"

[dependencies]
core = "2.1.0"

[canisters.user_service]
main = "src/user_service/main.mo"

[canisters.content_service]
main = "src/content_service/main.mo"

Motoko

src/shared/Types.mo — Shared Types

module {
  public type UserId = Principal;
  public type PostId = Nat;

  public type UserProfile = {
    id : UserId;
    username : Text;
    created : Int;
  };

  public type Post = {
    id : PostId;
    author : UserId;
    title : Text;
    body : Text;
    created : Int;
  };

  public type ServiceError = {
    #NotFound;
    #Unauthorized;
    #AlreadyExists;
    #InternalError : Text;
  };
};

src/user_service/main.mo — User Canister

import Map "mo:core/Map";
import Principal "mo:core/Principal";
import Array "mo:core/Array";
import Time "mo:core/Time";
import Result "mo:core/Result";
import Runtime "mo:core/Runtime";
import Types "../shared/Types";

persistent actor {

  type UserProfile = Types.UserProfile;

  let users = Map.empty<Principal, UserProfile>();

  // Register a new user
  public shared ({ caller }) func register(username : Text) : async Result.Result<UserProfile, Types.ServiceError> {
    if (Principal.isAnonymous(caller)) {
      return #err(#Unauthorized);
    };
    switch (Map.get(users, Principal.compare, caller)) {
      case (?_existing) { #err(#AlreadyExists) };
      case null {
        let profile : UserProfile = {
          id = caller;
          username;
          created = Time.now();
        };
        Map.add(users, Principal.compare, caller, profile);
        #ok(profile)
      };
    }
  };

  // Check if a user exists (called by other canisters)
  public shared query func isValidUser(userId : Principal) : async Bool {
    switch (Map.get(users, Principal.compare, userId)) {
      case (?_) { true };
      case null { false };
    }
  };

  // Get user profile
  public shared query func getUser(userId : Principal) : async ?UserProfile {
    Map.get(users, Principal.compare, userId)
  };

  // Get all users
  public query func getUsers() : async [UserProfile] {
    Array.fromIter<UserProfile>(Map.values(users))
  };
};

src/content_service/main.mo — Content Canister (calls User Service)

import Map "mo:core/Map";
import Nat "mo:core/Nat";
import Array "mo:core/Array";
import Time "mo:core/Time";
import Result "mo:core/Result";
import Runtime "mo:core/Runtime";
import Error "mo:core/Error";
import Principal "mo:core/Principal";
import Types "../shared/Types";

// Import the other canister — name must match icp.yaml canister key
import UserService "canister:user_service";

persistent actor {

  type Post = Types.Post;

  let posts = Map.empty<Nat, Post>();
  var postCounter : Nat = 0;

  // Create a post — validates user via inter-canister call
  public shared ({ caller }) func createPost(title : Text, body : Text) : async Result.Result<Post, Types.ServiceError> {
    let originalCaller = caller;

    if (Principal.isAnonymous(originalCaller)) {
      return #err(#Unauthorized);
    };

    // Inter-canister call to user_service
    let isValid = try {
      await UserService.isValidUser(originalCaller)
    } catch (e : Error.Error) {
      Runtime.trap("User service unavailable: " # Error.message(e));
    };

    if (not isValid) {
      return #err(#Unauthorized);
    };

    let id = postCounter;
    let post : Post = {
      id;
      author = originalCaller; 
      title;
      body;
      created = Time.now();
    };
    Map.add(posts, Nat.compare, id, post);
    postCounter += 1;
    #ok(post)
  };

  // Get all posts
  public query func getPosts() : async [Post] {
    Array.fromIter<Post>(Map.values(posts))
  };

  // Get posts by author — with enriched user data
  public func getPostsWithAuthor(authorId : Principal) : async {
    user : ?Types.UserProfile;
    posts : [Post];
  } {
    let userProfile = try {
      await UserService.getUser(authorId)
    } catch (_e : Error.Error) { null };

    let authorPosts = Array.filter<Post>(
      Array.fromIter<Post>(Map.values(posts)),
      func(p : Post) : Bool { p.author == authorId }
    );

    { user = userProfile; posts = authorPosts }
  };

  // Delete a post — only the author can delete
  public shared ({ caller }) func deletePost(id : Nat) : async Result.Result<(), Types.ServiceError> {
    let originalCaller = caller;

    switch (Map.get(posts, Nat.compare, id)) {
      case (?post) {
        if (post.author != originalCaller) {
          return #err(#Unauthorized);
        };
        ignore Map.delete(posts, Nat.compare, id);
        #ok(())
      };
      case null { #err(#NotFound) };
    }
  };
};

Production Readiness: Content Service

The content service examples above are intentionally kept simple to demonstrate multi-canister communication patterns. They lack several things that would be needed for production use:

• Input validation. The username parameter in register accepts any string — including empty strings or strings up to the 2MB message size limit. Validate length (e.g., 1–64 characters), enforce allowed character sets, and add a uniqueness constraint via a reverse lookup map to prevent impersonation.
• User enumeration and pagination on getUsers. Using getUsers, it's possible for everyone to enumerate all users on the platform, which may not be desirable. Furthermore, the getUsers endpoint returns all user profiles in a single response. As the user base grows, this will hit the 2MB response size limit and trap, bricking the endpoint. Add pagination (offset/limit parameters). The same applies to getPosts.

Rust

Project Structure (Rust)

my-project/
  icp.yaml
  Cargo.toml          # workspace
  src/
    user_service/
      Cargo.toml
      src/lib.rs
    content_service/
      Cargo.toml
      src/lib.rs

Cargo.toml (workspace root)

[workspace]
members = [
  "src/user_service",
  "src/content_service",
]

icp.yaml (Rust)

canisters:
  - name: user_service
    recipe:
      type: "@dfinity/rust@v3.3.0"
      configuration:
        candid: src/user_service/user_service.did