RealTime Communication

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.

Understanding WebSockets in relation to  Pub/Sub

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

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.

Understanding the tools we have for our System Design 

Pub/Sub Communication on AWS

These services are ideal for decoupling producers and consumers, broadcasting messages, and building event-driven systems.

1. Amazon SNS (Simple Notification Service)

• 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.

2. Amazon EventBridge

• 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.

3. Amazon MQ

• 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.

4. Amazon Kinesis Data Streams

• 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.

6. Amazon MSK (Managed Streaming for Apache Kafka)

• 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.

1. Amazon API Gateway (WebSocket APIs)

• Native support for WebSocket protocol.

• Fully managed, scalable, serverless.

• Integrates with Lambda, DynamoDB, and other AWS services.

• Great for lightweight real-time apps.

2. AWS AppSync (with GraphQL Subscriptions)

• 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.

3. AWS IoT Core

• WebSocket support through MQTT over WebSockets.

• Ideal for IoT device communication, especially when using publish/subscribe with low latency.

• Scales to millions of devices.