Event sourcing and Big Data

Recently, I checked the event sourcing mode and found that it is quite consistent with my potential goals.

In software development, objects usually perform logical operations in the memory, and then the final state of objects is persisted to the database. If,CodeIf an execution error occurs, we can only reverse the error based on the final result. However, the general result is that we cannot find out why this happens, especially in high concurrency!

It is usually complicated to solve these problems. This error is triggered at a specific time. If it cannot be reproduced, you may not be able to figure out the code execution sequence. Event sourcing can help solve such problems. Event sourcing is used to create a trail application.ProgramStatus events, and then the events are persisted in order. It is foreseeable that when the status of these applications changes, you can re-track the application from the initial status based on the sorted events to locate the cause of the error.

The problem I encountered recently is a bit similar to this: some users have incorrect usernames or passwords during logon, and these errors cannot be identified as user input errors, or a problem in the program. Therefore, event sourcing is introduced to the login application, so that the user's logon execution sequence can be tracked through the user name and time. For Internet applications, the data generated every day should be very large, and hadoop will naturally be introduced to query large data volumes.

Well, this is what we have to do recently ~