From 1633d4605f13642dcac9a51c6e0347e56843c27c Mon Sep 17 00:00:00 2001
From: Pavels Kletnojs <18351609+kletnoe@users.noreply.github.com>
Date: Wed, 18 Mar 2026 13:33:10 +0200
Subject: [PATCH] Typo in publish-subscribe-semantics.md

---
 markdown/blog/publish-subscribe-semantics.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/markdown/blog/publish-subscribe-semantics.md b/markdown/blog/publish-subscribe-semantics.md
index 9a9e5a9ac1ea..337be7e04462 100644
--- a/markdown/blog/publish-subscribe-semantics.md
+++ b/markdown/blog/publish-subscribe-semantics.md
@@ -54,7 +54,7 @@ If you were implementing an application to honour the contract described in an O
 
 # What about AsyncAPI?
 
-In an event driven architecture there is no client/server paradigm. Applications do not directly communicate with one another - instead, each application sends and receives events via communication channels provided by s messaging infrastructure such as a broker. The broker ensures that events sent to a channel are delivered to interested applications. It can be considered *fire and forget* - an application sends an event, but does not have any interest in whether other applications receive or make use of the event.
+In an event driven architecture there is no client/server paradigm. Applications do not directly communicate with one another - instead, each application sends and receives events via communication channels provided by a messaging infrastructure such as a broker. The broker ensures that events sent to a channel are delivered to interested applications. It can be considered *fire and forget* - an application sends an event, but does not have any interest in whether other applications receive or make use of the event.
 
 AsyncAPI approaches this by describing an application as having two potential roles: