Skip to main content

Pattern: Feeder (Materialized View)

Description​

The Feeder Pattern is a strategy used to mitigate performance issues in systems with heavy read/reporting requirements. It involves a "Feeder" component that pre-calculates or aggregates data from the transactional store and writes it to a simplified "Read Model" (or Materialized View).

Although often implemented ad-hoc in legacy systems, it matches the CQRS (Command Query Responsibility Segregation) principle: separating the Write Model (Complex Normalized Entities) from the Read Model (Flat, Optimized Tables).

Context in WepNG​

  • Module: WA (Work & Travel).
  • Implementation: WADataFeederBiz, WAYTDFeeder.
  • Role: These classes likely run periodically (or on trigger) to update a separate set of tables or cache entries used specifically for the Reporting Dashboard.

Benefits​

  1. Read Performance: The dashboard queries the pre-calculated "Feeder" table, which is instant (Select *).
  2. Isolation: Complex joins and logic happen during the "Feeding" phase, not during the "Reading" phase (User interaction).

Risks (Anti-Pattern if done wrong)​

  1. Synchronization Lag: The "Feeder" table is eventually consistent. Users might not see data immediately.
  2. Logic Duplication: If the Feeder logic drifts from the Core Business Logic (e.g., Price Calculation), reports become invalid.
  3. Trigger Complexity: If implemented via many triggers or complex "Dirty Checking", it becomes fragile.