Flux Architecture and Redux

Problem Explain the Flux architecture and why you would reach for Redux.

Be ready to discuss

• Flux's unidirectional data flow: Actions -> Dispatcher -> Stores -> View, and back to Actions - one direction, always.
• The problem it solves: MVC's two-way binding and cascading updates make it impossible to reason about who changed what in a large app.
• Redux's simplifications over classic Flux: a single store instead of many, and the reducer replacing the dispatcher's registration/waitFor machinery.
• The three principles: single source of truth, state is read-only and only changed by dispatching actions, and changes are made by pure reducer functions.
• Why reducer purity matters: same state + same action always yields the same next state, which is what makes testing trivial and time-travel debugging possible.
• Actions as serialisable descriptions of "what happened" rather than "what to change" - and how that gives you a replayable audit log.
• Middleware for side effects: thunks, sagas, and where async work belongs since reducers must stay pure.
• The honest counterpoint: Redux's boilerplate and when Context + useReducer, React Query, or Zustand are the better fit.