Do "architectural spikes" of both. This means: set a reasonable time-box for the work (typically a day), make sure the work is totally hands-on (build out as much of each competing solution as possible), throw away the spiked work when done, and only then have a discussion to decide. One way to make this more effective is to get each sub-team to spike the other sub-team's proposal. This makes sure that you don't end up with a "fallacy of sunk costs" problem after the spikes are completed. Any theoretical argument will tend towards "analysis paralysis". Doing hands-on work is much more effective for discovering the best solution.
In Sprint Planning, this is an allocation of capacity to learning instead of implementation. As long as it doesn't consume your whole Sprint and the team still works on a potentially releasable product increment (in addition to the learning from the spikes), you should be able to stay on-track.
Another way to say this: arguing takes more time than just trying out the alternatives.
Interestingly, making an arbitrary decision is also better than trying to argue out the "correct" solution since it gives your team an opportunity to inspect and adapt faster. Argument is almost always waste.
As Ken Schwaber, founder of Scrum says, "use Scrum to build the wrong thing in a month" (paraphrased) and then "inspect and adapt".