Building Event-Driven Systems at Scale with Cosmos DB
summary
Claims that Azure Cosmos DB can serve as an event store and transactional outbox at scale, using transactional outbox plus the change feed to project reads asynchronously; documents must stay under 2 MB, logical partitions cap at 20 GB, physical partitions ~50 GB with ~10,000 RU limits, and 1 KB reads ≈1 RU. Built an append-only event store, change-feed processors (Azure Functions) to create snapshots and publish to brokers, and the demo runs successfully.
AI-written summary · about
chapters (10)
- 0:00Event-driven systems with Cosmos DB
- 3:12Event-driven architecture scaling
- 8:24Cosmos DB scalability features
- 15:07Partitioning logical vs physical
- 21:02CAP theorem and consistency levels
- 26:14Change feed processing
- 30:59Event sourcing and projections
- 35:15Live demo event processing
- 37:52Optimizing performance and costs
- 38:24Q&A
related talks
20mHow Azure Cosmos DB enables Event Sourcing architecture
01h 01mServerless & Schemaless with Azure Functions and CosmosDB
33mDriver for Data-Driven Change - Azure Cosmos DB Performance, Security & Cost Optimization Done Right
21mBuild Scalable Inventory System with Azure Cosmos DB
52mEvent journal in Azure (no Cosmos inside)
20mHow Azure Cosmos DB enables Event Sourcing architecture and powers e-commerce
01h 13mBuilding Planet Scale .NET Apps with Azure Cosmos DB
27mAzure Cosmos DB Changefeed tales from the trenches