I think, I won't be able to explain Redux to a 5 year old kid. But recently I came through an explanation provided by @Linclark about Redux. I hope that will partially answers your question.

1. The view requests an action. The action creator formats it and returns it.
2. The action is either dispatched automatically (if bindActionCreators() was used in setup), or the view dispatches the action.
3. The store receives the action. It sends the current state tree and the action to the root reducer.
4. The root reducer cuts apart the state tree into slices. Then it passes each slice to the subreducer that knows how to deal with it.
5. The subreducer copies the slice and makes changes to the copy. It returns the copy of the slice to the root reducer.
6. Once all of the subreducers have returned their slice copies, the root reducer pastes all of them together to form the whole updated state tree, which it returns to the store. The store replaces the old state tree with the new one.
7. The store tells the view layer binding that there’s new state.
8. The view layer binding asks the store to send over the new state.
9. The view layer binding triggers a rerender.

Source : code-cartoons.com/a-cartoon-intro-to-redux-3afb77…

Credits : Lin Clark

I found this diagram, I think is the most basic to understand what Redux do

You have a single store where the state of your whole application relies. One of your React components can dispatch or "trigger" an action (for example by clicking a button). Every action returns an object with a "type" property which is usually a string that serves as an identifier of the action. The reducer intercepts that action to know what to do with state on the store. The reducer do something in the state (update, add, remove, etc) and the new state of the store returns to your React components to update (if it is necessary) the interface.

The flow is always the same, it can be intimidating at first and challenging if you come from the MVC world like me but after a while you get use to it.

If you like to learn more, the Redux webiste is really good to learn the best practices in using Redux (read and understand the three principles and you're good to go). You can even learn Redux from its creator for free :)

These are some complicated answers. I will try and be short.

Imagine Redux is a grocery store. You made the store and know what is inside of it. You yourself can not go inside but can send someone in to get things for you (actions).

The reason you can't go in is you might mess something up while you are there and you might blame someone else for your actions. This is why you send someone else to fetch and return (dispatch) your goods. If they mess something up then you know what action made the mistake.

This is how I would explain it. The store is immutable because you cannot go in yourself. The actions go in and dispatch your info back to you. You have better debugging from this because you can track mistakes made by your actions.

Helps you to avoid the use of "setState"

Let me try, even thou English is not my main language ...

Redux (the Flux methodology) is based on having an only source of truth, the state object, which will be kept available by all the reducers, and a only one way of updating the data and showing it on your views.

Initially, the components you connect to certain parts of this state are subscribed to the changes it may suffer along the way, and will represent the data on your views, but different to the common mvc pattern, the only way to alter the state from any components is via the use of action creators.

Action creators are functions that calculate or fetch data, hold or use the logic you need, to send the reducers an/some/many actions (objects with a part of the current state you'd want to change). All actions need a type, and different payloads depending on what you may want to change, so the reducers can mix/merge/assign new data to the current state to produce a new state (yes, the state should never be mutated, you always get a new one!). These are normally triggered by user actions, but could also be internal state so your views can tell the user when something is loading, or has an error, ie.

Reducers, finally, are switches that are subscribed to the different parts of the state, pretty much as your components, but also to your actions, so when a particular action is fired, some reducer subscribed to this action can then mix the state with this piece of data and return the new state. There can be several reducers listening to the same action type, and all of them are passed through your actions as you are composing your root reducer..

Does this help?