Following Feed Development for Mobile Apps

Following Feed Development for Mobile Apps

Building a following feed that works smoothly with 100K+ followers is nontrivial. A simple SQL query SELECT * FROM posts WHERE author_id IN (SELECT followee_id FROM follows WHERE follower_id = :user) ORDER BY created_at DESC breaks under scale: with 1M followers and 10M posts, response time exceeds 3 seconds. Add realtime requirements, instant startup, and a popular author with a million followers—and without a solid architecture, it's infeasible. A hybrid fan-out for average users and fan-in for stars reduces infrastructure costs by 30-50%. Our team, with 7+ years of experience and 50+ social app projects, delivers a solution that handles the load. We conduct load testing with k6 at 1000 RPS before project delivery.

Choosing the Architecture: Fan-in or Fan-out?

Two classic approaches: fan-out on write (push) and fan-in on read (pull). With fan-out, a new post is immediately written to all followers' feeds—fast reads but expensive writes for popular authors. Fan-in assembles the feed on read from subscriptions—no data duplication, but slower reads. In practice, a hybrid is used: fan-out for typical users (author has up to 100K followers) and fan-in for "stars" with millions of followers. The threshold is configurable. For an MVP, fan-in is sufficient:

SELECT p.*, u.name, u.avatar_url FROM posts p JOIN follows f ON p.author_id = f.followee_id JOIN users u ON p.author_id = u.id WHERE f.follower_id = :user_id AND p.created_at < :cursor ORDER BY p.created_at DESC LIMIT 20; 

Indexes: follows(follower_id), posts(author_id, created_at DESC). With this query, response time is 100-150 ms for 1M subscriptions.

Fan-out reads are 1000x faster than fan-in for average users with 100 followers, but fan-in writes are 200x faster for stars with 1M followers.

Cursor-Based Pagination vs Offset

Cursor-based pagination handles a query in 50 ms on a 10M-row table, while OFFSET on page 100 takes up to 2 seconds (40x slower). We use the created_at timestamp of the last post (ISO 8601) as cursor: GET /feed?cursor=LAST_SEEN_POST_TIMESTAMP&limit=20 Response: { items: [...], next_cursor: "...", has_more: true }.

Implementation is straightforward: an index on (created_at) gives O(log n) lookups. Unlike OFFSET, cursor is insensitive to insertions—no duplicates appear.

How to Ensure Instant Feed Loading?

Client-side caching is the answer. On iOS with Swift, we save the first 50-100 feed posts in CoreData or Realm. On app launch, show the cache instantly while simultaneously requesting new posts. When new posts arrive, silently insert them at the top or show a banner. Use NSFetchedResultsController + NSDiffableDataSourceSnapshot for smooth updates without flickering. On Android with Kotlin, use Room + Paging 3 with RemoteMediator. The local database is the source of truth; RemoteMediator loads network data into Room, Paging 3 renders from Room. On Flutter, use Hive or Isar for local cache, flutter_bloc for page state management.

Caching cuts initial data loading by 80% and reduces traffic by 60%.

Realtime Updates: Strategies and Implementation

• Pull to refresh – user pulls down, request posts newer than firstPost.created_at. Simplest, works everywhere.
• WebSocket/SSE – server pushes new posts to client. Show a banner "X new posts" at the top of the feed (like Twitter). The client does not auto-insert them – only on banner tap, to avoid feed jumping.
• Long polling – a compromise without WebSocket.

On iOS WebSocket – URLSessionWebSocketTask. On Android – OkHttp WebSocket. On Flutter – web_socket_channel.

Setup Realtime Updates via WebSocket

1. Open WebSocket connection when entering the feed.
2. Server sends new_post event with post ID.
3. Client shows banner "X new posts".
4. On banner tap, load missing posts via API.

Algorithmic Feed

Chronological feed is the base. If you need algorithmic ranking (by engagement), store a score per post and recalculate via a worker (BullMQ/Celery) when likes/comments are added. The client requests feed with sort=ranked. For first launch, use chronological; after data accumulation, switch to algorithmic. Offer both as separate tabs (Reels vs Following like Instagram).

Scrolling and Performance

UICollectionView with UICollectionViewCompositionalLayout and DiffableDataSource is the gold standard on iOS. Prefetch data via UICollectionViewDataSourcePrefetching. Images – Kingfisher with memory and disk caching. On Android, LazyColumn (Compose) or RecyclerView with ConcatAdapter. Images – Coil with rememberAsyncImagePainter. The main reason for jerky scrolling is image decoding on the main thread. Kingfisher and Coil do this in the background by default. With custom loading, use DispatchQueue.global(qos: .userInitiated).async (iOS) or Dispatchers.IO (Android).

What's Included

• Architectural scheme for the feed (fan-in/fan-out/hybrid) tailored to your load.
• API with cursor-based pagination and realtime events.
• Feed UI with cache and smooth scrolling.
• Load testing (k6) for the scenario "1000 simultaneous feed requests".
• Documentation, code, and deployment support.

Timelines and Costs

Basic feed with pull-to-refresh and pagination – 2-3 days, cost $3,000-$5,000. With realtime WebSocket, cache, algorithmic ranking – 7-10 days, cost $10,000-$15,000. Larger projects with custom ranking algorithms can reach $25,000. Cost is calculated individually based on required features and load. Contact us for a project assessment – we guarantee a transparent approach and certified developers. Get a consultation from an engineer.