Avoiding fan traps in database design and system diagrams(ilograph.com)
ilograph.com
Avoiding fan traps in database design and system diagrams
https://www.ilograph.com/blog/posts/avoid-fan-traps-in-system-diagrams/
4 comments
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
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.
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?