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.
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.