When you are trying to solve an architecturally challenging problem, you can come up with several decisions, all solving the problem, but in different ways.
Next step is choosing one out of the alternatives, when you start thinking about pros and cons of each. If you have found the right answer after this step, then you are good to go. However, sometimes the decision seems to be difficult, because of one or more from the following reasons:
Whichever the case, it's not the end of the world, nor does it mean that you are not good enough at architecting. It simply means that at this moment, the difference does not really matter.
It's very natural for the software development lifecycle to change its direction and values several times, especially if you are using adaptive (iterative) development processes. In such case, simply pick the one that seems to be simpler, or is extensible to the other one if necessary (find out which one is a specific case for the other, and pick more general one).
It would be much worse, if you start inventing value for the software that does not exist (biased value). If you do so, you might end up making statements that can become rules or constraints for the later time, thus creating useless challenges for yourself. So, simply let it go and declare the selected solution as something that can be changed after things become clear.
Another argument is time - don't spend it on questions that don't matter. Things that matter will not let you rest assured, so you will come back to them right after you read this topic. Otherwise, you have already made the decision.
"Simplicity is the ultimate sophistication" - Leonardo da Vinci.