{"id":13005,"date":"2026-10-01T09:00:12","date_gmt":"2026-10-01T16:00:12","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=13005"},"modified":"2026-10-02T05:13:20","modified_gmt":"2026-10-02T12:13:20","slug":"genspark-protects-live-agent-sessions-with-azure-cosmos-db-global-secondary-indexes","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/genspark-protects-live-agent-sessions-with-azure-cosmos-db-global-secondary-indexes\/","title":{"rendered":"Genspark protects live agent sessions with Azure Cosmos DB Global Secondary Indexes"},"content":{"rendered":"

This article was authored by Justin Liu, co-founder and chief architect, Genspark.<\/em><\/p>\n

The work does not end when the prompt does<\/h2>\n

A user comes to Genspark<\/a> with a goal: research a market, build a presentation, produce a report, analyze a dataset, or complete another complex assignment. Our agents take it from there, working across tools, sources, and multiple steps until the user has a finished result.<\/p>\n

The request may fit in a sentence; the actual work of the request, though, rarely does.<\/p>\n

One assignment can involve repeated searches, decisions, tool calls, and revisions. Throughout the process, the agent relies on fast-changing operational state\u2014including project context, conversation history, task progress, file metadata, and usage events. Each step builds on the last, so access to current state helps keep the work moving.<\/p>\n

That operating pattern is why we chose Azure Cosmos DB. Agent traffic is bursty and difficult to predict, so we needed low-latency reads and writes with throughput that could scale with demand. We also wanted the database to carry more of the operational burden. With a small engineering team and no dedicated database-operations function, having Azure Cosmos DB handle scaling, replication, and availability mattered more than any single feature. It also fits naturally with the rest of the Azure platform Genspark runs on and has grown with us from a consumer product to Team and Enterprise offerings.<\/p>\n

As Genspark grew, the same operational data began supporting two kinds of work. Live agent sessions needed current state as they moved through a task. Internal workflows also returned to parts of that data, often with read-heavy workloads of their own.<\/p>\n

Those background reads were invisible to users, yet they still drew on the same capacity serving live traffic. When background activity increased, an agent could pause while assembling a report or moving between steps. The platform continued processing the workload, though the experience could become less predictable.<\/p>\n

We considered moving those reads to a separate replica. Doing so would also have meant building or operating a replication or ETL pipeline, checking synchronization, monitoring another system, and planning for failures.<\/p>\n

That was more infrastructure than we wanted to add for work happening behind the scenes. We needed a way to separate the workloads without creating another production system for our team to operate. Azure Cosmos DB Global Secondary Indexes gave us a path to do that within the database environment we already used.<\/p>\n

Isolating background reads with a global secondary index<\/h2>\n

Azure Cosmos DB Global Secondary Indexes<\/a> (GSI) gave us another read path without requiring a separate replication stack.<\/p>\n

Live reads and writes continue to use the source container. We route selected background processes to the GSI, and Azure Cosmos DB automatically keeps the two in sync with change feed.<\/p>\n

We started with a focused use case that isolated selected read-heavy internal processes. The goal was to keep that work from drawing on the same capacity as active agent sessions.<\/p>\n

That focus made the change easier to evaluate. We could move a specific group of readers, observe how they behaved, and leave the user-facing data path as it was.<\/p>\n

\"Diagram<\/a><\/p>\n

 <\/p>\n

 <\/p>\n\n\n\n\n\n\n
Architecture component<\/strong><\/td>\nRole<\/strong><\/td>\n<\/tr>\n
\u00a0Source container<\/td>\nServes live reads and writes, including operations that require the freshest available state<\/td>\n<\/tr>\n
Global Secondary Index<\/td>\nServes selected read-heavy background processes<\/td>\n<\/tr>\n
Azure Cosmos DB<\/td>\nAutomatically syncs changes between the source container and the global secondary index<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Matching workloads to eventual consistency<\/h2>\n

Once the separate read path was available, the important decision was what belonged there.<\/p>\n

In Azure Cosmos DB, a GSI is eventually consistent with the source container. Some of our background processes can work from a recent view of the data. Others need the latest state available.<\/p>\n

We used a simple question to tell them apart: What breaks if this data is behind?<\/strong><\/p>\n

For the processes we moved, eventual consistency did not change the outcome or affect an active session. They could continue working safely even when the GSI had not fully caught up. Reads tied to the latest operational state stayed on the source container.<\/p>\n

The Azure Cosmos DB team helped us work through that boundary. Before routing production traffic to the GSI, we reviewed how eventual consistency would affect each process and which ones could safely tolerate a lagging copy.<\/p>\n

We then tested those choices against real synchronization behavior, watching the selected processes both when the GSI was caught up and when it trailed the source container. Once we confirmed they continued to run safely in both conditions, we completed the move.<\/p>\n

Workload isolation without another system to run<\/h2>\n

The GSI gave us the separation we needed without adding another system to run. Azure Cosmos DB keeps the index synchronized, so we did not have to build and maintain a replication service of our own.<\/p>\n

That matters for a small team. Every extra moving part takes time to monitor, troubleshoot, and support\u2014time we would rather spend improving the product.<\/p>\n

We also kept the first use case narrow. We knew which processes we wanted to move, who relied on their output, and if they could tolerate eventual consistency. After testing them against real synchronization behavior, we were confident they could run safely on the GSI.<\/p>\n

In the end, we separated background work from live traffic without turning it into a larger architecture project. Live sessions get the capacity they need, background processes keep running, and our team can stay focused on Genspark.<\/p>\n

 <\/p>\n

About Genspark<\/strong><\/p>\n

Genspark is an AI agent workspace built for knowledge workers worldwide. Its agents take on the work that fills a knowledge worker’s day\u2014research, presentations, reports, data analysis\u2014and carry it from goal to finished result. One of the fastest-growing AI products to date, Genspark serves millions of users across the globe, from individuals to organizations on its Team and Enterprise plans. Learn more at genspark.ai<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

This article was authored by Justin Liu, co-founder and chief architect, Genspark. The work does not end when the prompt does A user comes to Genspark with a goal: research a market, build a presentation, produce a report, analyze a dataset, or complete another complex assignment. Our agents take it from there, working across tools, […]<\/p>\n","protected":false},"author":179851,"featured_media":13011,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1980,14],"tags":[],"class_list":["post-13005","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure-cosmos-db","category-core-sql-api"],"acf":[],"blog_post_summary":"

This article was authored by Justin Liu, co-founder and chief architect, Genspark. The work does not end when the prompt does A user comes to Genspark with a goal: research a market, build a presentation, produce a report, analyze a dataset, or complete another complex assignment. Our agents take it from there, working across tools, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/posts\/13005","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/users\/179851"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/comments?post=13005"}],"version-history":[{"count":3,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/posts\/13005\/revisions"}],"predecessor-version":[{"id":13010,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/posts\/13005\/revisions\/13010"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/media\/13011"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/media?parent=13005"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/categories?post=13005"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cosmosdb\/wp-json\/wp\/v2\/tags?post=13005"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}