Microsoft Loop Architecture

As an avid user of OneNote since its release back in 2003, and a not so-recent convert to what I think is a more modern version, Microsoft Loop, which I have been promoting for a while, I was asked by a few, if I can shed light on the inner workings of the product. Here is one I shared recently with a developer community.

In a nutshell: Loop is:

• based on the Fluid framework introduced by Microsoft: https://fluidframework.com/docs/, https://github.com/microsoft/FluidFramework

• hosted and executed in Azure via the fluid relay service: https://portal.azure.com/#browse/Microsoft.FluidRelay%2FfluidRelayServers
• content persisted in SharePoint Embedded (SPE), where Loop workpaces are stored as SPE sites: https://learn.microsoft.com/en-us/sharepoint/dev/embedded/overview

*I am an early adopter of SPE and have participated in its product design meeting and believe to have helped shape its current state through the monthly product managers' meetings.

1. Loop architecture

1. Clients: Users can open and edit Loop content in a Browser (Loop web interface) or directly within Office apps (Teams, Outlook, OneNote). Regardless of the client, all collaborative actions ultimately go through the same Fluid Loader process to locate and load the container.
2. Fluid Loader Document Service Factory: Manages connection to back-end services (SPE and the Fluid Service). Container Code Loader: Dynamically loads the container’s code and data store definitions. Scopes & Permissions: Ensures that only authorized clients can access or modify the container. URL Resolver: Interprets the Loop workspace/page URL, determining which SPE site and container to load.??
3. Fluid Runtime (Container) Maintains one or more Data Stores, each containing Distributed Data Structures (DDS) for real-time updates. Interacts with SPE for persistent storage. Uses the Fluid Service (e.g., Azure Fluid Relay) to broadcast operations (ops) among connected clients.??
4. SPE (SharePoint Engine) Primary content store where Loop workspaces are hosted as individual SPE sites. Stores persistent data for pages and components so they can be accessed across different clients.
5. Fluid Service Manages the real-time flow of operations between clients. Ensures each user sees immediate updates, regardless of which client they use.

2. URL Resolution and Container Loading

When a user opens a Loop page or component (in a browser or Office client), the Fluid Loader processes the URL to locate and load the correct container.

1. URL: Could be a link shared within Teams, an Outlook email, or a Loop page in a browser.
2. Container Lookup & SPE Resolver: Identifies the correct SPE workspace/site and container reference.
3. Fluid Service Driver: Connects to the Fluid Service to manage real-time messaging.
4. Container Code Loader: Dynamically loads the data store code needed for collaboration.
5. Scopes & Permissions: Applies any necessary authorization checks.
6. Fluid Container or Shared Object: The loader returns a handle that the client uses to read/write shared data in real time.

The diagram below illustrates this flow:

3. Loop Process Flow & Real-Time Synchronization

After the container is loaded, all user actions become Fluid operations (ops) that the Fluid Service broadcasts to other connected clients. This ensures that browser users, Teams users, and Outlook/OneNote users see changes as they happen:

• Client1 performs an action in the Loop interface (e.g., editing text, changing a table).
• The Fluid Container packages this change into a delta and sends it to the Fluid Service.
• The Fluid Service relays the delta to Client2 (any other client connected to the same container).
• Client2 applies the operation locally, reflecting the updated state in real time.
• The container also interacts with SPE to persist changes so they are available to future sessions.

Overall end-to-end architecture