Data Management Patterns Flashcards
What is the cache aside pattern
Applications implement a cache to improve repeated access to information held in a data store. If the data isn’t in the cache then the application fetches the data and places it in the cache
What is read through caching?
Data is read from a cache by a client. If the data isn’t present in the cache it’s first read by a loader that knows how to access the data of record.
link to source
What is write through caching
The cache is configured with a writer component that knows how to write to the system of record. When a value is written to the cache it’s written to the system of record by the writer and the cache
link to source
What are considerations when implementing the cache aside pattern?
- Lifetime of cached data - how long to keep data in the cache if it’s not used
- Evicting data - decide what data to remove from fixed size cache
- Priming the cache - prepopulate the cache with data.
- Consistency - not guaranteed between the cache and the data store
- Local(in memory) cache - multiple copies of the data in different applications leads to inconsistency
What is the CQRS pattern
It’s the command and query responsibility segregation pattern
What are the characteristics of the CQRS pattern
Reads and writes for a data store are separated. Reads and write workloads are asymmetric and typically have different PSR requirements.
Goal is to have separate models where writes would have validation logic and read operations may involve many different queries with different data transfer objects
What are the common implementation characteristics of the CQRS pattern?
Writes are treated as commands that are tasked based(e.g., book hotel room vs set reservation status to reserved)
Queries never modify the data store. No domain knowledge is encapsulated in data transfer objects returned
What are the 5 benefits of the CQRS pattern?
- Independent scaling - read/write workloads can scale independently
- Optimized data schemas - reads use schemas optimized for reading. Writes use schema optimized for writing
- Security - easier to ensure right domain entities are making changes
- Separation of concerns - separating reads/writes can result in simpler models which are easier to maintain. Read model usually simple while write model contains the more complex validation logic.
- Simpler queries - a materialized view in the data base reduces the needs for complex joins
What are 3 implementation considerations to be aware of for CQRS?
Complexity, Messaging, Eventual consistency
- Complexity - more complex application design
- Messaging - common to use messaging stack. Need to deal with failures and duplicate messages
- Eventual Consistency - If db’s are separate for read/write then read db needs to be sync’d when writes occur. Difficult to detect stale data on reads
When is using the CQRS pattern appropriate?
- Collaborative domains where many users access same data in parallel. Define granular commands to minimize merge conflicts at the domain level
- Domain models have complex steps and/or domain models. Writes are complex in that they maintain consistency and validate user input. The Read model has no business logic and returns highly de-normalized views
- Independently tune Read/write performance
- Separate teams work on read and write models
- System evolves over time. Multiple versions of the model exist. Business rules change frequently.
- Integration with systems where the temporary failure of one subsystem shouldn’t effect the availability of others
What is the Event Sourcing pattern?
Handles operations on data that’s driven by a sequence of events each of which is recorded in an append only store. Each event represents a set of changes to the data.
link to source
What are the advantages of the Event Sourcing pattern?
- UI/workflow isn’t blocked. It posts and event and continues.
- Less likely to encounter contention during processing of transactions
- Promotes extensibility and flexibility through decoupling events from tasks
- Helps prevent conflicts from concurrent updates
- Lends itself to acting as an audit trail for actions(updates, compensating events) taken with an external data store
link to source
What are the characteristics of Events in the Event Sourcing Pattern?
- Events are immutable.
- Events are simple and don’t directly update the data store
- Events are recorded for processing at a later time
- Events have meaning for a domain expert
- Events processing is decoupled from event source.
- Consistency of events in the event store is vital, as is the order of events that affect a specific entity
link to source
What are the consumer of events in the Event Sourcing pattern?
Tasks consume events.
link to source
What are the characteristics of event consumers in the Event Sourcing pattern?
- They know about the event and event data.
- They don’t know about the operation that raised the event.
- Event publication might be at least** **once, and so consumers of the events must ensure idempotent behavior.
link to source
What are the considerations when using the Event Sourcing pattern?
- The system will only be eventually consistent when creating materialized views or generating projections of data by replaying events.
- There’s some delay between an application adding events to the event store
- The application must still be able to deal with inconsistencies that result from eventual consistency and the lack of transactions
link to source
When using the Event Sourcing pattern how do you deal with large streams of events?
If the streams are large, consider creating snapshots at specific intervals such as a specified number of events
link to source
When using the Event Sourcing pattern how do you get the “current” state for an entity?
Need to replay all of the events that relate to it against the original state of that entity
When using the Event Sourcing pattern for updating an entity how is a change to that entity made?
The only way to update an entity is to undo an existing change by adding a compensating event to the event store.
From a migration perspective what is important to consider when using the Event Sourcing Pattern
Use versioning on messages to old messages can be properly identified and converted to new format messages when they’re played back as part of recreating the event history
What is the Index Table Pattern
Create Indices over fields in data stores that are frequently referenced by queries
What problem is the Index Table Pattern solving?
Secondary indices are common on relation db’s but a lot of nosql data bases don’t provide this capability. This pattern suggests ways to implement your own secondary indices on top of such a datastore
