Flux vs middleware architecture pattern for an auction flow

We are in the process of refactoring a complex auction flow into a more functional style pattern and contemplating whether to use a middleware based approach or perhaps a flux-based pattern.

The auction currently has a lot of side-effects at each step, no single instance or class of anything that represents the auction as a whole, and is always adding new business logic that adds new steps for filtering, mutating and enriching/tagging auction-related properties.

Our proposal is to refactor the auction so that it follows a unidirectional functional style for easier debugging and simplicity. Side-effects and mutations should either be restricted or more controlled, we should have a unified log or history object for each auction so that it can be easily debugged.

One approach is to follow a unidirectional pattern, either:

1. A middleware pattern like express and have each module perform its business logic and pass control and an append-only history to the next function in the auction.

2. Or, we can follow the flux architecture with actions and reducers, and an auction store or reducer

Would the flux architecture be appropriate in this situation? Or is it over-complicated and a middleware approach be simpler?

Our main motivations are to wrangle an ever-increasing complexity of business logic into something that can easily be tested and debugged, along with lightening fast performance.