In event-driven systems, teams should not call another service's API, but instead consume its events and maintain local state. However, how much state should they store? If teams limit themselves to the state that is needed at the moment, they may find themselves rushing to deal with changes in requirements over a number of sprints. If they store all the state, then they end up being coupled to the other team's schema evolution.

In every architecture review, this decision comes up, gets discussed in a Slack thread, and is regretted six months later. However, most teams lack a systematic approach to evaluating it.

In this talk, Jeroen will walk attendees through the range of options, from making REST calls to full event replication. He will share examples of teams that kept too little data and teams that kept too much, and provide a practical decision-making framework based on four criteria: topic retention, schema stability, requirements clarity, and query patterns.

Attendees will leave with a method they can use to assess this trade-off in their own systems. It won't be a set of rules, but rather a structured approach that recognizes there is no one-size-fits-all solution.

What Jeroen will cover:

• The spectrum: REST calls, thin projections, full event replication, raw event storage, and when each approach breaks down
• Real examples of teams that stored too little and teams that stored too much, and what it cost them
• A decision framework built on four axes and how to apply it in an architecture review