
Ask HN: Any event sourcing systems that use source files for persistence? - erikpukinskis
I&#x27;ve been thinking about event sourcing while also trying to whittle down the number of languages in play in my stack.<p>It occurred to me that if you&#x27;re doing event sourcing, you could just persist actual source code that replays the log, i.e. just dump something like this to the filesystem and keep appending to it:<p><pre><code>    createUser(&quot;rbg@scotus.gov&quot;, &quot;dj85jig&quot;)
    createUser(&quot;knope@nps.gov&quot;, &quot;b85kee6&quot;)
    befriend(&quot;dj85jig&quot;, &quot;b85kee6&quot;)
</code></pre>
It seems like people usually persist to a traditional database, which gets you acces to that whole ecosystem of tools. But source files seem like a natural fit for event sourcing and I&#x27;m curious if there are examples of this approach in use? Cautionary tales?
======
jrpt
Is the aim to do event sourcing for later data analysis or to actually base
your app's business logic off of the events?

I have some experience with using events to construct the final state for data
analysis. (If you didn't mean for data analysis, just ignore this comment) The
problem with trying to reconstruct data at some final state based on events is
that the meaning of the events change over time. For instance, createUser
might do one thing in January, then something slightly different in April
(e.g. sets a default value to be 10 instead of 5). It becomes a nightmare to
try to get the final table to be accurate, and if you try, your reconstruction
script ends up with a bunch of if/then cases based on the history of the
program generating the events.

You still probably want to log the events, but it looks like you are hoping to
recreate the users table based on your createUsers history, which would run
into the problem I mentioned above.

If you do log data straight to files, you can always analyze it with something
like Splunk or Kibana (and if you use Kibana, you probably just log the events
with the ELK stack). Still, it's way easier to analyze data with a relational
database because of the tools built around SQL, and it's already familiar to
analysts whereas Splunk's proprietary language is something they'd have to
learn.

If you end up using SQL, I suggest
[https://aws.amazon.com/redshift/](https://aws.amazon.com/redshift/) for the
data warehouse, and [http://DataDuckETL.com/](http://DataDuckETL.com/) for
getting the data into Redshift.

------
twunde
We've done something similar where we log requests along with parameters to a
sql table. One thing to beware is to make sure you're not logging passwords,
credit card info, ssns or other types of pii.

