Expected performance by Use-case
When designing for real-time communication, the meaning of “real-time” varies based on context:
Audio: Delays beyond 150ms start to interfere with natural conversation, causing noticeable pauses or talk-over issues.
Video: To maintain smooth playback, aim for latency under 200ms—anything more can make the stream feel jittery.
Interactive applications (e.g., UI updates, live data): Latency should stay below 100ms to keep the experience feeling immediate and responsive.
User experience threshold: A web response time ranging between 200 milliseconds and 1 second is considered acceptable as users still likely won't notice the delay
Async Communication
While WebSockets are often associated with real-time, interactive user experiences, they’re also effective for implementing synchronous communication patterns between an application and its backend. In scenarios where the backend needs to coordinate with slow or unreliable third-party services, WebSockets can provide a persistent channel to manage this interaction more efficiently.
For example, using AWS’s store-first design pattern, an application can immediately acknowledge a user action, persist the request to a durable store like DynamoDB or S3, and then offload the processing to background workflows (e.g., AWS Lambda or Step Functions). Here, WebSockets can be used to keep the app updated on the progress or result without blocking the UI or polling repeatedly.
Since the primary goal isn’t to meet sub-100ms performance thresholds for perception, the latency constraints of real-time UX don't apply. Instead, this pattern enhances reliability and user trust by decoupling the frontend responsiveness from backend dependencies—delivering updates only when meaningful changes occur, without compromising the frontend’s speed or stability.
WebSocket is a communication protocol designed to provide real-time, two-way communication between clients and servers over a single, long-lasting connection.
AWS WebSocket Implementations
1. AWS API Gateway WebSocket APIs
2. AWS AppSync (GraphQL with WebSocket)
3. AWS IoT Core with MQTT ( WebSocket/MQTT)
Pub/Sub (Publish/Subscribe) is a messaging pattern where publishers send messages to a central message broker, and subscribers receive messages they've specifically registered interest in, without direct client-server communication. Pub/Sub excels in distributed systems, enabling robust, scalable communication between multiple independent services, making it ideal for microservices architectures and event-driven systems.
AWS Pub/Sub Implementations
Amazon SNS, Amazon SQS, Amazon kenisis , AWS IoT Message Broker, Amazon MQ, AppSync,
The key difference is that WebSocket (via API Gateway or AppSync) provides direct persistent connections for real-time communication, while SQS, SNS, and EventBridge are message-oriented services designed for different service-to-service communication patterns and use cases.
Pattern
Pub/Sub for notifications & fan-out
Real-time data streaming with processing/replay
Low-latency, bi-directional communication
Integration with third-party/legacy systems
IoT messaging at scale
Best Fit
SNS, EventBridge
Kinesis, MSK
API Gateway (WebSocket), AppSync
Amazon MQ
AWS IoT Core
Understanding the tools we have for our System Design
These services are ideal for decoupling producers and consumers, broadcasting messages, and building event-driven systems.
Fully managed pub/sub messaging.
Push-based: supports delivery to SQS, Lambda, HTTP(S) endpoints, email, SMS, etc.
Good for fan-out patterns.
Not persistent—messages not retained after delivery.
Event bus system for routing events between services.
Supports custom events and integrates with AWS services and SaaS platforms.
Rule-based routing.
Great for microservices and decoupled event-driven architectures.
Managed message broker (ActiveMQ or RabbitMQ).
Supports traditional pub/sub messaging with topics and queues.
Useful when migrating legacy systems that rely on broker-based messaging.
Use case: Ingest and distribute large volumes of real-time data (logs, telemetry, analytics).
Supports multiple consumers: Multiple apps can "subscribe" to the stream and process data independently.
Pub/Sub-like behavior: Yes — multiple consumers reading from the same stream = pub/sub model.
Durability: Stores data for 24 hours (default) to 365 days.
Delivery model: Consumers pull data (not push-based like SNS).
5. Amazon Kinesis Data Firehose
Use case: Near real-time delivery to destinations (e.g., S3, Redshift, OpenSearch).
Not used for traditional pub/sub — more for data pipeline automation.
Managed Kafka cluster.
High-throughput, persistent pub/sub messaging.
Ideal for real-time analytics, event streaming, and complex event processing.
WebSocket Communication on AWS
WebSockets are useful for bi-directional, persistent connections, commonly used in real-time apps like chat, collaborative tools, and live dashboards.
Native support for WebSocket protocol.
Fully managed, scalable, serverless.
Integrates with Lambda, DynamoDB, and other AWS services.
Great for lightweight real-time apps.
Real-time data synchronization using GraphQL subscriptions (over WebSockets under the hood).
Ideal for mobile/web apps needing live updates (e.g., chat, collaborative editing).
Works with DynamoDB, Lambda, Aurora, etc.
WebSocket support through MQTT over WebSockets.
Ideal for IoT device communication, especially when using publish/subscribe with low latency.
Scales to millions of devices.
Kinesis, while capable of pub/sub, is designed primarily for high-throughput, ordered, and durable streaming data pipelines
— more aligned with event streaming and analytics pipelines than lightweight pub/sub or WebSocket needs.
Kinesis = Pub/Sub for high-scale, real-time data streaming.
SNS/EventBridge = Lightweight, decoupled pub/sub for microservices and events.
API Gateway/WebSockets = Real-time, bi-directional app communication.