1. What is a Fanout Service?

A fanout service is a service that receives a single request and then distributes (fans out) that request to multiple downstream services.

Think of it like a teacher giving a task to students: the teacher (fanout service) tells many students (downstream services) to do their part.

Example in software:

You have a service that receives a new order.
This order needs to be processed by:
- Payment service
- Inventory service
- Shipping service
The fanout service takes the order and “fans out” the message to all these services.

2. Fanout Models: Pull vs Push

There are two main ways a fanout service can distribute requests: Push model and Pull model.

A. Push Model

In a push model:

The fanout service actively sends requests to downstream services.
Each downstream service doesn’t ask for the data; the fanout service delivers it automatically.

Analogy:

You (fanout service) are a teacher. You go to each student and hand them the homework. The students don’t have to ask; you push it to them.

Pros:

Simple and fast.
Downstream services get the message immediately.

Cons:

If a downstream service is busy or down, it may miss messages unless you implement retries or queues.
Can overload downstream services if too many requests are pushed at once.

Example in tech:

Using HTTP calls: The fanout service calls each downstream API.
Using Kafka with topics: Fanout service produces messages, consumers process immediately.

B. Pull Model

In a pull model:

The downstream services ask the fanout service for new requests.
The fanout service doesn’t push anything automatically.

Analogy:

Teacher posts the homework on a notice board. Students check the board when they are ready and take the homework themselves.

Pros:

Downstream services can control when and how fast they process requests.
Less chance of overwhelming services.

Cons:

Slight delay in processing (services might not check frequently).
More complex to implement if you need guaranteed delivery.

Example in tech:

Using message queues (like RabbitMQ or Kafka): Consumers pull messages from the queue at their own pace.
Database polling: Service queries database for new records.

3. Quick Comparison Table

Feature	Push Model	Pull Model
Who initiates?	Fanout service	Downstream service
Speed	Fast	Dependent on poll frequency
Reliability	Needs retry logic	More reliable if queue used
Load control	Hard (can overwhelm)	Easy (consumer controls)
Use case	Real-time updates	Asynchronous processing

4. When to Use Which

Push model: Real-time notifications, when you want low latency. Example: Webhooks.
Pull model: When downstream services are slow, busy, or unreliable, or you want controlled consumption. Example: Queue-based processing.

🔹 Fanout in News Feed Systems

“Fanout” = distributing posts from one user to many followers. When User A posts, that post needs to be delivered to all followers’ feeds.

There are two approaches: Push-based fanout and Pull-based fanout.

1️⃣ Push-based Fanout

👉 As soon as a user creates a post, push it to all their followers’ feed timelines.

Flow:

User A creates a post.
System writes that post into every follower’s feed storage (denormalization).
When followers open their feed → posts are already there.

✅ Advantages

Fast read: Feeds load instantly because posts are pre-written.
Good for users with moderate followers (most common case).

❌ Disadvantages

Write amplification: If a user has 10M followers (celebrity), one post = 10M writes.
Wasted storage/writes if many followers never check the feed.

2️⃣ Pull-based Fanout

👉 Store posts only in the author’s “outbox” and fetch them on-demand when a follower opens their feed.

Flow:

User A creates a post.
Post stored in User A’s timeline storage (outbox).
When User B (follower) opens their feed → system fetches posts from all people they follow, merges, sorts, and shows.

✅ Advantages

Efficient writes: Only one write per post (to author’s storage).
Avoids write explosion for celebrities.

❌ Disadvantages

Slow reads: Fetching + merging feeds at read time is expensive.
Not scalable if a user follows thousands of people (expensive to query all timelines).

3️⃣ Hybrid (Real Systems Use This)

Most large systems (Facebook, Twitter, LinkedIn) use a hybrid of push + pull:

For normal users: Push fanout → precompute feeds.
For celebrities (millions of followers): Use pull fanout → followers fetch their posts on demand.

👉 This balances read performance and write scalability.

🔹 Example in News Feed

Imagine Virat Kohli posts:

If we push to 100M followers → system crashes.
Instead, system stores Virat’s post in his timeline (outbox).
For most followers → when they open feed, system pulls Virat’s posts dynamically.

But if you post to your 200 friends, it’s fine to push it directly into their feeds.

✅ In short:

Push = precompute feeds → fast read, expensive writes.
Pull = compute feeds on demand → cheap writes, expensive reads.
Hybrid = best of both worlds.