Skip to main content
SDMastery

Push vs Pull Architecture

In push architecture, the server sends data to clients when events occur (WebSockets, webhooks, push notifications).

Quick answer: Push vs Pull Architecture

Push vs Pull Architecture is covered here as a practical architecture tradeoff. In push architecture, the server sends data to clients when events occur (WebSockets, webhooks, push notifications). Use it when comparing two architecture choices and explaining the operational cost, latency, reliability, and team-complexity impact of each option.

Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.

Related reading path

Diagram showing the key components and data flow in a Push vs Pull Architecture system design
High-level overview of Push vs Pull Architecture

The Tradeoff

In push architecture, the server sends data to clients when events occur (WebSockets, webhooks, push notifications). In pull architecture, clients request data when they need it (HTTP polling, REST API calls).

Push: A Closer Look

Server proactively sends data to clients. Events trigger immediate delivery.

System architecture diagram for Push vs Pull Architecture showing how services, databases, and caches connect
System architecture for Push vs Pull Architecture

The Good

  • Real-time updates
  • Lower latency
  • Efficient — no wasted requests

The Bad

  • Requires persistent connections
  • Harder to scale (track all subscribers)
  • Client must handle unsolicited messages

Pull: A Closer Look

Clients request data on their own schedule. Standard HTTP request-response.

Step-by-step diagram showing how Push vs Pull Architecture processes a request from start to finish
How Push vs Pull Architecture works step by step

The Good

  • Simple to implement
  • Stateless server
  • Easy to scale and cache

The Bad

  • Latency (polling interval)
  • Wasted requests when no new data
  • Not truly real-time

Quick Comparison

PushPull
Best forReal-time features (chat, notifications)Standard APIs

Real-World Examples

Comparison table for Push vs Pull Architecture contrasting approaches, tradeoffs, and when to use each
Comparing key aspects of Push vs Pull Architecture

Gmail uses push (IMAP IDLE) for real-time email notifications, but the web UI polls for updates.

Twitter uses fan-out-on-write (push) for users with few followers and fan-out-on-read (pull) for celebrities with millions of followers.

GitHub uses webhooks (push) to notify CI/CD systems of new commits.

Interview Advice

Data flow diagram for Push vs Pull Architecture showing how requests and responses move through the system
Data flow through Push vs Pull Architecture

Twitter's hybrid approach is a great interview example: push timelines for normal users (fast reads), pull for celebrity tweets (avoid writing to millions of follower timelines).

Source | System-Design-Overview

Real-World Decision Framework

In a push architecture, the server sends data to clients when new data is available. In a pull architecture, clients periodically request data from the server. This fundamental choice shapes real-time behavior, resource usage, and scalability.

Tradeoff analysis for Push vs Pull Architecture listing advantages, disadvantages, and real-world considerations
Advantages and disadvantages of Push vs Pull Architecture

When Push Architecture Wins

Push is ideal when timeliness matters and you have a manageable number of active connections. Examples:

  • Chat applications: WhatsApp and Slack push new messages to connected clients via WebSocket.
  • Live notifications: Facebook pushes notification badges the moment someone likes your post.
  • Stock tickers: Trading platforms push price updates every millisecond to active traders.
  • Collaborative editing: Google Docs pushes character-by-character changes to all viewers.

Technologies: WebSockets, Server-Sent Events (SSE), gRPC streaming, Firebase Cloud Messaging.

When Pull Architecture Wins

Production deployment examples of Push vs Pull Architecture at companies like Netflix, Google, and Amazon
Real-world examples of Push vs Pull Architecture

Pull is better when data freshness requirements are relaxed and you have many consumers. Examples:

  • Email clients: Gmail checks for new emails every few minutes rather than maintaining a permanent connection.
  • RSS feeds: Podcast apps poll feeds every hour to check for new episodes.
  • API integrations: Third-party apps poll your REST API for updated data.
  • Monitoring dashboards: Prometheus pulls metrics from application endpoints every 15 seconds.

Technologies: REST APIs with polling, RSS/Atom feeds, Prometheus scraping.

The Fan-Out Problem

The key scalability concern with push is fan-out. When a celebrity tweets to 50 million followers, pushing that tweet to all followers simultaneously creates a massive write amplification. Twitter solves this with a hybrid approach: push to followers with fewer than 10,000 connections (most users), pull for celebrity tweets (computed on read).

Decision guide for when to choose Push vs Pull Architecture and when alternative approaches are better
When to use Push vs Pull Architecture

Decision Checklist for Interviews

  1. How many consumers? Few → push. Millions → consider pull or hybrid.
  2. How fresh must data be? Real-time → push. Minutes OK → pull.
  3. Is the connection persistent? Yes (WebSocket) → push. Stateless (HTTP) → pull.
  4. What is the write-to-read ratio? High writes → pull (avoid write amplification). High reads → push.

.NET Implementation

Push: Use ASP.NET Core SignalR for real-time push over WebSocket with automatic fallback to Server-Sent Events and long polling. Pull: Standard REST API endpoints with ETags and conditional requests for efficient polling. Use IMemoryCache to avoid database hits on repeated polls.

Original DosiBridge notes for Push vs Pull Architecture

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Push vs Pull Architecture is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

  • Decision Boundary: For Push vs Pull Architecture, decide the decision boundary before choosing tools; otherwise the design looks clean but fails when push changes.
  • Reversal Cost: For Push vs Pull Architecture, decide the reversal cost before choosing tools; otherwise the design looks clean but fails when vs changes.
  • Operating Cost: For Push vs Pull Architecture, decide the operating cost before choosing tools; otherwise the design looks clean but fails when pull changes.
  • Team Maturity: For Push vs Pull Architecture, decide the team maturity before choosing tools; otherwise the design looks clean but fails when architecture changes.
  • Growth Trigger: For Push vs Pull Architecture, decide the growth trigger before choosing tools; otherwise the design looks clean but fails when push changes.

Production review question

If a team adopts Push vs Pull Architecture, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track push-architecture health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Push vs Pull Architecture, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

Original Sourcearticle