Postmortem Stage 1
Status: Work in progress
| Version | Date | Author | Status | Description |
|---|---|---|---|---|
| 0.1 | 2025-08-14 | isierra | WIP | Initial version |
In this document we will analyze the patterns and practices that went wrong or could be improved in the first stage of the project. The goal is to learn from these experiences to enhance future stages, as well as propose some refactorings.
Successful Practices
Areas with some Issues
Entity Workflows are too complicated
Kiota as an HTTP Client generator
Use of NATS is a bit fragile or badly understood
Too many libraries for each service
Too many models to map between layers
Solution 1: Move Aggregate code to DataAccess Layer
Pros
- Remove Events and Aggregates from Models libraries
- Less moving parts for aggregate implementation
Cons
- Aggregate command logic is moved away from business logic
Use of FeatureResult for error handling
Solution 1: Use Exceptions instead of FeatureResult
Pros
- Easier to propagate errors up the call stack
- Can include more context about the error
- More readable happy paths in code
Cons
- May introduce performance overhead
- Can make control flow harder to follow
- Requires additional boilerplate for try/catch blocks
Optimize some Read Models
User Sessions Read Model could be optimized to avoid loading the session through Temporal + Postgres every time the Accessoperation is requested.
Solution 1: Cache User Sessions in Orleans + Redis
List Pagination
Skip + Offset pagination is not efficient for large datasets.
Solution 1: Use Cursor-based pagination
Pros
- More efficient for large datasets
- Avoids issues with data changes between requests
- Can provide a more seamless user experience
- Requires separating counting from listing
Cons
- More complex to implement
- Requires changes to API contracts
- May require additional client-side logic
- Harder to implement “go to page” functionality
- Requires separating counting from listing