Avoiding fan traps in database design and system diagrams

This is an excellent breakdown of a subtle but critical modeling problem. The analogy to event-driven architectures is spot on.

We face a structurally similar challenge in investment simulation, but with time-series data. A user's portfolio is the central hub ("event broker"), and historical market events (drawdowns, volatility spikes, earnings) are the producers/consumers. If we model relations naively, we lose which specific historical regime caused a given rule violation.

Our solution aligns with your "Solution 1: More specificity": we pre-compute and tag regime-specific metrics (e.g., "max drawdown during 2020 Q1", "volatility during 2018 Fed hikes"). This allows the engine to answer "why was this stock excluded?" with a precise historical scenario, not just a generic violation.

Question: In your experience, is there a performance/readability trade-off threshold where adding this specificity (like your firewall rules or our regime tags) becomes counterproductive for the diagram (or system) comprehension?

Solution 4: Break the fan. Change it into smaller boxes each with the fan name.

Service A -> Firewall -> Service X

Service C -> Firewall -> Service Z

as opposed to the narrow waist? (see also: ip protocol) which is an amazing superpower.