In event-driven systems you should not call another service's API but instead consume its events and maintain local state. However, how much state should you store? If you limit yourselves to the state that is needed at the moment you will find yourself having to rush to deal with changes in requirements over a number of sprints. If you store all the state then you 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 considering it.

In this talk, I’ll walk you through the range of options, from making REST calls up to full event replication. I’ll share examples of teams that kept too little data and teams that kept too much, and I'll hand you a practical decision-making framework based on four criteria: topic retention, schema stability, requirements clarity, and query patterns.

You'll end up with a method that you can use to assess this trade-off in your 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 we'll cover:
- The spectrum: REST calls, thin projections, full event replication, raw event storage, and when each 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 your next architecture review

Target audience: Intermediate-to-advanced developers and architects building event-driven systems

Preferred format: Technical session (50 minutes).

Based on architecture guidance and real examples observed across teams at large Dutch enterprises.

Technical requirements: standard projector setup, no live coding. Prepared code snippets and diagrams in slides.