典型的なメッセージキューの実装では、システムアドミニストレータがメッセージキューソフトウェア（キューマネージャ）をインストール・設定し、名前のついたメッセージキューを定義する。アプリケーションは、そのキューにメッセージが置かれるのを待つソフトウェアルーチン（リスナー）を登録する。別の（複数の）アプリケーションがそのキューに接続し、メッセージをそこに転送する。キューマネージャは受信側アプリケーションが接続するまでメッセージを蓄積しておき、接続した時点で登録されたソフトウェアルーチンを呼び出す。受信アプリケーションは適切な方法でメッセージを処理する。
これには様々なバリエーションが存在する。例えば、次のような点である。
これらは、システムとしての意味論、信頼性、効率などを具体的にどうするかといった設計上の考慮すべき点である。
標準とプロトコル.
歴史的には、メッセージキューはプロプライエタリな閉鎖的プロトコルとして使われ始めたもので、そのために異なるOSやプログラミング言語を含めた環境の構築が制限されていた。
メッセージキューをより遍在的にする初期の試みとして、サン・マイクロシステムズのJMS仕様があり、JavaによってクライアントAPIを抽象化して異機種間接続を可能にしていた。これによりJavaを使えばメッセージキューのプロバイダーを切り替え可能となっており、SQLによってデータベースの切り替えが可能になったのと似ている。しかし実際にはメッセージキューの技法やシナリオは非常に多様であり、JMSが常に有効というわけではない。
これらの標準化や採用の段階はそれぞれ異なる。いずれもHTTPと同じレベルで運用される。
同期と非同期.
これらの場合、例えば情報の受け手がクラッシュしてしまっている可能性もあり、送信側が応答を待つのは適切ではない。