3factor app - Reliable Eventing

We discuss the second factor of Hasura's 3factor app, Reliable Eventing, as Allen says he still _surfs_ the Internet (but really, does he?), it's never too late for pizza according to Joe, and Michael wants to un-hear things.

This episode's full show notes can be found at https://www.codingblocks.net/episode116, just in case you're using your podcast player to read this.

Sponsors

• Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
• O'Reilly Velocity Conference – Get expert insight on building and maintaining cloud native systems. Use the code BLOCKS during registration to get 20% off of most passes.
• Educative.io – Level up your coding skills, quickly and efficiently. Visit educative.io/codingblocks to get 20% off any course.

Survey Says …

What's the first thing you do when picking up a new technology or stack?

 

Take the survey here: https://www.codingblocks.net/episode116.

News

• Thank you to everyone that left us a review:
  • iTunes: !theBestCoder, guacamoly, Fishslider
  • Stitcher: SpottieDog
• We have photographic evidence that we were in the same room with Beej from Complete Developer at Atlanta Code Camp. 

The Second Factor – Reliable Eventing

• Don't allow for mutable state. Get rid of in memory state manipulation in APIs.
• Persist everything in atomic events.
• The event system should have the following characteristics:
  • Atomic – the entire operation must succeed and be isolated from other operations.
  • Reliable – events should be delivered to subscribers at least once.

Comparing the 3factor app Eventing to Traditional Transactions

Traditional application	3factor application
Request is issued, data loaded from various storage areas, apply business logic, and finally commit the data to storage.	Request is issued and all events are stored individually.
Avoid using async features because it's difficult to rollback when there are problems.	Due to the use of the event system, async operations are much easier to implement.
Have to implement custom recovery logic to rewind the business logic.	Recovery logic isn't required since the events are atomic.

Benefits of an Immutable Event Log

• Primary benefit is simplicity when dealing with recovery. There's no custom business logic because all the event data is available for replayability.
• Due to the nature of persisting the individual event data, you have a built in audit trail, without the need for additional logging.
• Replicating the application is as simple as taking the events and replaying the business logic on top of them.

Downsides of the Immutable Event Log

• Information isn't (instantly) queryable, not taking into account snapshotting.
  • CQRS (command query responsibility segregation) helps to answer this particular problem.
• Forcing event sourcing on every part of the system introduces significant complexity where it may not be needed.
• For evolving applications, changing business needs require changes to the event schema and this can become very complex and difficult to maintain.
  • Upcasting: converting an event record on the fly to reflect a newer schema. Problem with this is you've now defeated the purpose of immutable events.
  • Lazy upcasting is evolving the ev