Facts and Projections—event-based time modeling
Temporal coupling series, part 2: An event-based approach to modeling time
Hey, this is Denis. This is a three-part series on the topics of modelling time in code, the engineering concepts surrounding temporality and co-dependence between teams. This is part two in the temporal coupling series:
Micro-services solve Time, not Size
Facts vs projections, an event-based approach to modeling time
How your team’s communication cadence impacts architecture
Facts
Engineers like to interchangeably use the word event for facts. We are not delving into the semantics today. Greg Young is writing a book on it, let’s be patient. For software systems facts help us reason about state changes that are important enough to be persisted.
The core issue you’ll explore today is the difference between events and forecasts. Facts and speculation. Past, present and future.
Mechanically, records of persisted data changes about certain outcomes in the past are facts.
Let’s say today is December 1st.
The fact that a booking has been received today for a stay on Christmas is a certainty. The guests showing up and on which date is not.
Not at this time.
What happens first?
Bring your attention to the last sentence in the previous chapter. Not at this time. This brings us into the realm of temporal coupling. What is the order of things? Well despite the blue box being in the future and the yellow/orange box in the past, for a single event the blue box comes before the orange one.
A factual event is created as a result of user intent. User intent is stimulated based on the state of a projection they observe on a UI. The UI is updated as a consequences of events updating in our persisted store.
There are situations where a step is skipped or the number of items changes (ie. delegation, fan-out, task automation). But the direction is always the same.
Impact on Collaboration
The direction of data flow controls the larger architectural avenues for coupling. Let’s take a simple (synchronous) REST example.
Team A affects team B’s events? A depends on B.
Team B notifies team A of state updates? A depends on B.
The UI requires state updates and uptime on commands from team A. It depends on A and B.
Events trail. Projections are just-in-time. Commands lead. Past, present, future.
In the example above, the team A should be the one owning their events, and defer projection to the UI or team B. This is common when sharing databases in monolith setups.
However, close the loop firmly and you get a synchronous request/response coupling, the strictest in architecture. The opposite of loosely coupled architectures, a staple characteristic of highly productive teams.
Get these lines mixed up without following your data flow and you’ll quickly find yourself applying back-pressure on the other teams:
Rejected PRs
Backward-incompatible changes
Additional sign-off on data-flow
Blast radius on data changes includes all neighbouring teams
The most common anti-pattern is having a web- and mobile-based UI with different command and data needs and having their projections be computed on a singular backend server. This is the problem GraphQL set out to solve.
The less encapsulation you have on your team, the more you’ll be sharing data. The less you understand another team’s the data, the more you’ll want to enrich detail to it.
Conclusion
A tidy data flow makes for easy team collaboration. Good team collaboration makes for tidy data flows. Chatty teams produce chatty APIs. Ensure your encapsulation and architecture follows your data flow and coupling needs.
You learned a few unintuitive rules
Past information and future intent have different coupling directions
Teams are affected by data dependencies
Mutability increases along the timeline. Data about the future is unreliable
Derivate data projections are always more volatile than their source data
In our next and last post in this series we’ll discuss how the structure and semantics of your teams, tribes and departments impact design and time-based coupling.
Did you like this post? I’d love to hear your feedback.