Design a BLoC solution for an API call that updates multiple UIs

WHAT THIS TESTS: This question tests whether you can architect BLoC patterns for cross-cutting concerns without creating tight coupling or brittle dependencies. The interviewer wants to see if you understand stream-based reactive architecture, separation of concerns, and how to handle partial failures across independent UI surfaces.

A GOOD ANSWER COVERS: First, propose a single source of truth for the API result such as a repository that exposes a Stream or a lightweight coordinator BLoC that emits a domain event like FilterApplied. Second, explain that each independent UI surface owns its own BLoC which subscribes to that stream via StreamSubscription in its constructor or a BLoC observer pattern, then maps the incoming data into its own localized state. Third, emphasize that loading and error states remain local to each consumer so one failing widget does not break the others; for example, a chart BLoC might show ChartLoading while a list BLoC shows ListError simultaneously. Fourth, mention cleanup by cancelling subscriptions in close or onDispose to prevent memory leaks. Fifth, optionally note that if the UI surfaces are truly independent, you could also use a reactive repository pattern with BehaviorSubject or similar so BLoCs receive the latest value on subscription without needing a coordinator.

COMMON WRONG ANSWERS: A major red flag is suggesting that one BLoC directly instantiates or imports another BLoC to call a method on it, because this destroys testability and creates hidden dependency graphs. Another anti-pattern is dumping all UI surfaces into a single giant state object with one BLoC; this forces every BlocBuilder to rebuild on any change and violates the principle of independent surfaces. Using global variables or static singletons to share mutable state is also wrong because it breaks encapsulation and makes widget testing impossible. Finally, ignoring stream cleanup or suggesting BlocListener chains inside the UI layer to ferry events between BLoCs shows a misunderstanding of where business logic should live.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a partial failure where the API call succeeds for one surface but another has cached stale data. They might also ask how to debounce rapid filter changes or how to implement optimistic updates across multiple BLoCs. Another common follow-up is whether you would use BLoC-to-BLoC communication directly via event sinks instead of a shared stream, which opens a discussion on why direct coupling is risky.

ONE CONCRETE EXAMPLE: Imagine an e-commerce filter sidebar and a product grid plus a summary bar. The user selects a price range which triggers FilterBloc to call the repository. The repository exposes a Stream of FilteredProducts. GridBloc and SummaryBloc each subscribe to that stream in their constructors. GridBloc emits GridLoadInProgress then GridLoadSuccess with products; SummaryBloc emits SummaryLoadSuccess with aggregate counts. If the grid throws a parsing error it emits GridError while the summary bar remains visible with prior data because the streams are independent. Each BLoC cancels its subscription in close.