<commit_before>---
title: Gateway
summary: NServiceBus enables durable fire-and-forget messaging across physically separated IT infrastructure.
tags: []
redirects:
 - nservicebus/introduction-to-the-gateway
---

This article, together with [the Gateway & Multi-Site Deployments](multi-site-deployments.md) article, provide a high level overview of the NServiceBus gateway, where to use it, and more importantly where not to use it. The main purpose of the gateway is to allow you to do the same durable fire-and-forget messaging that you are accustomed to with NServiceBus across physically separated sites, where "sites " are locations where you run IT infrastructure and not web sites.

The gateway only comes into play where you can't use the regular queued transports for communication i.e. when setting up a VPN-connection is not an option. The reason for not using a VPN could be security concerns, bandwidth limitation, latency problems, high availability constraints, etc.

## When not to use the gateway

The gateway should not be used when the reason for running separate sites is disaster recovery. Under those circumstances all your sites are exact replicas and are not logically different from each other, so you're better off using whatever support your infrastructure provides to keep your sites in sync. Examples are SAN snapshots, SQL server log shipping, and RavenDB replication.

So if your sites are logically similar, use one of the approaches above; if they are logically different, the gateway may come in handy.

## What are logically different sites?
<commit_msg>Update index.md<commit_after>---
title: Gateway
summary: NServiceBus enables durable fire-and-forget messaging across physically separated IT infrastructure.
tags: []
redirects:
 - nservicebus/introduction-to-the-gateway
---

The purpose of the gateway is to allow you to do the same durable fire-and-forget messaging that you are accustomed to with NServiceBus across physically separated sites, where "sites " are locations where you run IT infrastructure and not web sites.

The gateway only comes into play where you can't use the regular queued transports for communication i.e. when setting up a VPN-connection is not an option. The reason for not using a VPN could be security concerns, bandwidth limitation, latency problems, high availability constraints, etc.

## When not to use the gateway

The gateway should not be used when the reason for running separate sites is disaster recovery. Under those circumstances all your sites are exact replicas and are not logically different from each other, so you're better off using whatever support your infrastructure provides to keep your sites in sync. Examples are SAN snapshots, SQL server log shipping, and RavenDB replication.

So if your sites are logically similar, use one of the approaches above; if they are logically different, the gateway may come in handy.

## What are logically different sites?

{'fraction_non_alphanumeric': 0.04232983406705046, 'fraction_numerical': 0.0, 'mean_word_length': 4.76953125, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '215475', 'n_tokens_mistral': 699, 'n_tokens_neox': 643, 'n_words': 426}