If you want a guarantee that your configuration is going to be globally effective you really can't us the design mode to manage the configuration. There are strategies you can take to reduce duplication across templates but those are workarounds - design mode isn't intended to hold global configurations it's intended to hold design configurations specific to a particular location in the page or site.
With a requirement like this you'll have to create some central location in your repository where you store this configuration and then fetch from that location using the Sling APIs. Normally what I do is pick a level in my site hierarchy to hold these configurations - for example the node immediately below /content, or perhaps you language/locale node. Depending on how many properties I'll either manage it in the page properties of that page, or create a config component to hold the properties. In my component then I'll usually use page.getAbsoluteParent to get the right page object, and then use the Sling Resource API to get to the right now and get the property value.
You can also store the values in /etc somewhere if you wanted to. The advantage or storing it in your site hierarchy is that you can make your code self contained without any specific repository paths have to be hard coded.
You can also use a more inheritance based approach but that means you might be able to override those values at multiple levels.
