.NET event sourcing library with CosmosDB, DynamoDB, EventStoreDB, message-db, SqlStreamStore and integration test backends. Focused at stream level; see https://github.com/jet/propulsion for cross-stream projections/subscriptions/reactions
Resolves #403; Adjusts the write algorithm to ensure all newly appended events are always first written to the tip (as opposed to potentially going straight to a calf batch as they do in the Cosmos impl, which would generally be more optimal both in RU cost and in density of events per Batch/Item in the store)
This is to enable downstream consumers of the DDB Streams (including Propulsion.DynamoStore.Indexer) to be guaranteed to see all appends for a given stream in the correct order.
Prompted by observations and analysis by @epNickColeman that writes to non-tip events (calved batches) were arriving out of order under non-trivial write load (previous load tests had not included triggering the calving of ). On closer investigation, the documentation for DDB Streams turns out to be written very tightly to only guarantee ordering at the individual item level, not for relative positions of writes to the same logical partition (even in a transactional batch).
While the commits here bear my name, Nick and I paired on the implementation and cleanup, and the actual leg of work of figuring out the problem, convincing me it was real, and what the core of the fix needed to be was entirely due to his time, effort and insight 🙌
Resolves #403; Adjusts the write algorithm to ensure all newly appended events are always first written to the tip (as opposed to potentially going straight to a calf batch as they do in the Cosmos impl, which would generally be more optimal both in RU cost and in density of events per Batch/Item in the store)
This is to enable downstream consumers of the DDB Streams (including
Propulsion.DynamoStore.Indexer) to be guaranteed to see all appends for a given stream in the correct order.Prompted by observations and analysis by @epNickColeman that writes to non-tip events (calved batches) were arriving out of order under non-trivial write load (previous load tests had not included triggering the calving of ). On closer investigation, the documentation for DDB Streams turns out to be written very tightly to only guarantee ordering at the individual item level, not for relative positions of writes to the same logical partition (even in a transactional batch).
While the commits here bear my name, Nick and I paired on the implementation and cleanup, and the actual leg of work of figuring out the problem, convincing me it was real, and what the core of the fix needed to be was entirely due to his time, effort and insight 🙌