alt.hn

1/18/2026 at 12:34:57 PM

Avoiding fan traps in database design and system diagrams

https://www.ilograph.com/blog/posts/avoid-fan-traps-in-system-diagrams/

by billyp-rva

1/18/2026 at 12:42:34 PM

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?

by investbot

1/20/2026 at 10:28:20 PM

Got to love the relational model. Learned about fan traps in data modelling course at uni in the early 80s

by speedbird

1/20/2026 at 10:46:48 PM

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

by gardenhedge

1/21/2026 at 5:23:23 PM

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

by somat