My app is a GIS Server and we strongly need high availability. The reason to be master/master is to share load because we have a lot of users and as, this is an app for security sector, each node must be able to work alone to ensure availability all the time.
If that's a requirement, then you're going to need to write the application to cope with the consequences.
What if, while there's replication lag due to network issues, someone creates a row with id "42" in one node. Someone else creates a row with id "42" in the same table in another node?
The app has to be able to deal with that, or use things (like BDR's global sequences) to prevent it. And you can't always prevent it unless writeable tables are basically append-only, since two UPDATEs that affect the same row can also conflict.
So ... *if* you can review your application and change it where necessary to cope with the anomalies that can arise in asynchronous multi-master replication, BDR will be absolutely ideal for your needs. That's pretty much what it's for. But you need to be able to do that review and adjustment rather than just pointing your app at a couple of BDR nodes and hoping for the best.
BDR has conflict logging and conflict statistics features that will help you during testing, too; see the docs for details on them.