|
|
|
|
|
|
by bananaowl
922 days ago
|
|
|
The architecture from hell. Hard to debug. Why didn't my service pick up that event? Error handling. What happens with the state if a service throws an exception? Resource hog. How do I map/reduce all these events into a state? I do like events. They go into my elk stack where I can look at pretty graphs which gives me a story of how my system behaves over time. |
|
|
What event? If you're not event-sourcing, you can't even ask that question. Instead, some user interacted with the system and got a 500. Maybe you got a stack trace in the logs, but the user's data is gone (or maybe half of it was stored).
Persistent events mean you get to fix the problem and try again - no data lost.
> What happens with the state if a service throws an exception?
Whatever you programmed it to do. Same as any other service.
> How do I map/reduce all these events into a state?
There's no one way to store them like there is in an RDBMS. UserService listens to User events. TransactionService listens to Transaction events. SearchService listens to both. All three have different schemas. Those schemas can be thrown away and redesigned at any time without data loss.
Do a bad job of map/reducing them into a state today. Do it better tomorrow.