Course contents
On this page
Lesson plan 37: Application data architecture
Choose application transaction boundaries from business invariants and external effects.
Placement: Part 7: Building and operating applications on these engines.
Prerequisites: Lesson 36: Separated compute and storage, plus the earlier dependency chain.
Learning outcomes
- Choose application transaction boundaries from business invariants and external effects.
- Explain pooling, N+1 requests, outbox publication, and retry identity through complete request paths.
- Identify where service separation creates additional consistency and recovery protocols.
- Separate a general mechanism, a documented implementation choice, and an illustrative numerical assumption.
Teaching sequence
- Establish the motivating situation: A service commits an order then crashes before publishing the order-created message.
- Introduce the vocabulary and the correctness obligation before an optimization. Define transaction boundaries, access patterns, pools.
- Develop the mechanism: Use a transactional outbox and idempotent consumer; explain the remaining ordering and retention responsibilities.
- Follow the complete worked example: One parent query plus 100 child queries at 1 ms dependent RTT adds roughly 101 ms communication. Explain the assumptions, intermediate units, and limiting interpretation.
- Extend the scenario to changed load, skew, or failure, explaining N+1, outbox, side effects, service boundaries.
- Connect the mechanism to a documented implementation and an alternative with a different workload fit. Close by stating the remaining cost and the next lesson dependency.
Required chapter material
Use a complete execution trace or worked calculation, supported by an annotated static diagram or table. Include language-neutral pseudocode or labeled SQL when it clarifies the mechanism. State preconditions, ownership, visibility, and failure boundaries for algorithms. Describe operational costs as well as the normal path. All questions raised in the narrative must be resolved in the text.
Visual explanation
A purchase-and-outbox sequence shows one atomic database decision followed by at-least-once delivery and downstream deduplication. The accompanying prose explains the arrows, state changes, or table entries so the lesson remains understandable in a plain Markdown reader.
Editorial checks
Confirm that the numerical example agrees with its units and assumptions. Check that a faster path preserves the stated contract, or explicitly identify the changed guarantee. Keep hypothetical figures separate from product measurements. Explain both an appropriate use and a limitation of the case design. Check terminology against the glossary and links against the course index.