The architecture of a software is the collection of constraints a team agrees to adopt and maintain that will provide protection against mistakes.
Architecture is evolutionary, it must support evolving in time.
If the problem to be solved is pretty common , you should use a tried and tested architecture to it. (understanding the constraints of the architecture)
There is not a one size fits all generic good architecture. It must serve the needs to a system.
One of the must successful architecture is a layered system. E.g. UI, logic and database (using db transactions). For CRUD systems.
If you need transactions, make sure the database supports that.
Microservices where invented to be independent from each other, to decouple development. But it may be difficult to test them together before release.
If you need to test systems together before a release, you cannot work with microservices - you may be with a distributed monolith on your hands.
Architecting a hard problem from the start with much detail is overkill. Start as simple as possible, but keep it open to change with the least amount of work possible. This is an iterative and evolutionary process.
Think about the things you are unsure of. Insulate the things you understand from the ones you do not. As soon as someone says “I don’t know” for some aspect, treat that as a “Seam” (separate concern in the design).
Architecture should guide decisions with FEW constraints, rigidly enforced.