19 lines
1.6 KiB
Markdown
19 lines
1.6 KiB
Markdown
**Solutions Notes**
|
||
|
||
- The saga IS the domain model, so we can't make request-response calls from it of any kind (can't go get data)
|
||
- You start the saga at account creation
|
||
- The saga "never" ends (unless account is deleted, etc)
|
||
- The sage completes when it receives events that end the account
|
||
- The click messages come into the saga with a click sequence number. If the message currently being processed is not the next message (last click sequence is stored in the saga data) then we throw an exception and that message is retried later (eventually, hopefully, after the actual next message is processed).
|
||
- Everything after that is easy
|
||
- We have a 1 week timeout and a 2 week timeout for each purchase item command to know to decrement the 1 week running balance and 2 week running balance by the purchase amount to keep our week-based balances always up-to-date.
|
||
|
||
|
||
**Buy item (in-app purchase)**
|
||
Don't worry about mobile bit. Idea is to reward people to buy more quickly to encourage them to buy more quickly. Concern is that users are clicking really quickly. We've scaled out the handling over several machines. We used to do it with a traditional domain model. We did a select for orders over the last two weeks, then calculated the discount. Now we multi-thread it and two clicks might miss each other and a discount isn't applied. We need a model that will give users discounts that they deserve, but not give them discounts they don't deserve! Hint: saga!
|
||
|
||
- Multiple sagas?
|
||
- What starts the sagas?
|
||
- What happens when user runs out of funds?
|
||
- What ends the saga?
|
||
- What are the timeouts? |