How Instagram, WhatsApp, Uber & Netflix Would Be Built Today Using Expo Router
Learning web development in public. Writing simple, real-world explanations about web development concepts. Helping beginners understand why things work, not just how.
Modern mobile apps are no longer just a collection of screens connected together.
Apps like Instagram, WhatsApp, Uber, and Netflix operate at massive scale with millions of users, real time systems, offline support, complex navigation, caching layers, analytics, feature flags, and production-grade performance optimization.
If these apps were architected today in React Native, one of the strongest choices for navigation and scalable structure would be:
Expo
Expo Router
TypeScript
Feature-based architecture
Modern state management
API abstraction layers
Realtime infrastructure
Offline-first patterns
In this article, we’ll explore how apps like Instagram, WhatsApp, Uber, and Netflix could be structured today using Expo Router.
Why Architecture Matters in React Native Applications
Small apps can survive messy codebases.
Large apps cannot.
As applications scale, problems start appearing everywhere:
Navigation becomes difficult to manage
Shared state becomes chaotic
API calls get duplicated
Teams conflict with each other
Performance starts dropping
Startup time increases
Offline support becomes painful
Realtime systems become unreliable
Architecture is what prevents a codebase from collapsing under scale.
A good architecture improves:
Developer productivity
App performance
Maintainability
Scalability
Team collaboration
Feature isolation
Testing
At scale, architecture becomes a business decision, not just a coding preference.
Why Expo Router Changes Large-Scale App Structure
Traditional React Navigation setups often become deeply nested and difficult to maintain in large apps.
Expo Router changes this with:
File-based routing
Nested layouts
Route groups
Shared layouts
Better modularity
Cleaner mental models
Instead of manually wiring huge navigation trees, routes become part of the filesystem.
Example:
app/
├── (auth)/
│ ├── login.tsx
│ └── signup.tsx
│
├── (tabs)/
│ ├── home.tsx
│ ├── reels.tsx
│ ├── messages.tsx
│ └── profile.tsx
│
├── chat/
│ └── [id].tsx
│
└── _layout.tsx
This becomes extremely powerful as applications grow.
Folder Architecture for Large Applications
One of the biggest mistakes developers make is organizing apps by file type instead of by feature.
Bad structure:
components/
screens/
hooks/
utils/
services/
This works for small apps.
It becomes a nightmare for applications with hundreds of screens.
Modern large-scale apps prefer feature-based architecture.
Better structure:
src/
├── features/
│ ├── auth/
│ ├── chat/
│ ├── feed/
│ ├── rides/
│ ├── payments/
│ └── streaming/
│
├── shared/
│ ├── ui/
│ ├── hooks/
│ ├── utils/
│ └── services/
│
├── store/
├── api/
├── lib/
└── app/
Each feature owns:
Components
Hooks
Services
Types
API logic
State
Tests
This allows teams to work independently without constantly interfering with each other.
How Instagram Would Be Structured
Instagram is heavily content-driven.
Its architecture would prioritize:
Feed rendering performance
Image caching
Realtime engagement updates
Story systems
Background uploads
Deep linking
Recommendation systems
Possible feature structure:
features/
├── feed/
├── reels/
├── stories/
├── profile/
├── notifications/
├── messaging/
└── uploads/
Critical concerns would include:
FlatList optimization
Media preloading
Aggressive caching
Optimistic UI updates
Pagination systems
Skeleton loaders
Apps like Instagram depend heavily on rendering performance and perceived speed.
How WhatsApp Would Be Structured
WhatsApp is fundamentally a realtime communication system.
The architecture focus would include:
Socket reliability
Message synchronization
Offline queues
Encryption layers
Background processing
Low memory usage
Feature structure:
features/
├── chats/
├── calls/
├── contacts/
├── status/
├── groups/
└── media/
The biggest challenge is message consistency.
A modern architecture would likely include:
WebSocket layers
Local-first databases
Retry queues
Event synchronization
Optimistic delivery
Conflict resolution
WhatsApp-style apps are offline-first by design.
Messages must survive:
Poor internet
App restarts
Background kills
Device switching
How Uber Would Be Structured
Uber is a realtime location-based platform.
Its architecture priorities would include:
GPS streaming
Live ride tracking
Driver-rider synchronization
Payment reliability
Map rendering performance
Feature structure:
features/
├── maps/
├── rides/
├── drivers/
├── payments/
├── tracking/
└── support/
Realtime systems become the biggest engineering challenge.
The app constantly handles:
Driver movement updates
ETA recalculations
Route changes
Trip status changes
Surge pricing updates
This requires:
WebSockets
Efficient polling
Background tasks
Geolocation optimization
Event-driven architecture
How Netflix Would Be Structured
Netflix prioritizes performance and content delivery.
Its architecture focuses on:
Video startup speed
Recommendation systems
Personalized feeds
Smart caching
Device optimization
Feature structure:
features/
├── home/
├── player/
├── search/
├── downloads/
├── recommendations/
└── profiles/
Streaming apps optimize aggressively for:
Startup time
Rendering speed
Memory usage
Download management
Adaptive streaming
A modern Netflix-style app would likely include:
Offline download architecture
Progressive loading
Predictive prefetching
Analytics infrastructure
Navigation Architecture for Scalable Apps
Expo Router becomes extremely powerful in large apps because of nested layouts and route groups.
Example:
app/
├── (auth)/
├── (tabs)/
├── (modals)/
├── chat/
└── rides/
Each section can have its own layout:
// app/(tabs)/_layout.tsx
export default function TabLayout() {
return <Tabs/>;
}
Benefits include:
Independent navigation flows
Shared layouts
Cleaner mental models
Easier scalability
This becomes essential in apps with:
Deep linking
Protected routes
Dynamic screens
Nested tabs
Modals
Authentication Flow Architecture
Authentication is rarely just “login/signup.”
Large apps handle:
Session persistence
Token refresh
Multi-device sessions
Role-based access
Protected routes
Secure storage
Modern auth architecture:
features/auth/
├── api/
├── hooks/
├── screens/
├── store/
└── services/
Typical flow:
App boots
Restore token
Validate session
Load user profile
Hydrate app state
Route user correctly
Expo Router route groups help isolate authentication flows cleanly.
State Management Strategies for Large Apps
Small apps often overuse global state.
Large apps avoid it carefully.
Modern applications usually combine:
Zustand
React Query / TanStack Query
Context
Local component state
Typical separation:
| Type | Best Tool |
|---|---|
| Server state | React Query |
| UI state | Zustand |
| Form state | React Hook Form |
| Navigation state | Expo Router |
| Temporary state | useState |
The key principle is:
Keep server state separate from UI state.
This dramatically improves scalability and maintainability.
API Handling & Networking Layers
Large apps never scatter fetch calls everywhere.
Instead, they centralize networking logic.
Example:
api/
├── client.ts
├── auth.ts
├── feed.ts
├── rides.ts
└── chat.ts
Benefits include:
Centralized error handling
Retry systems
Request cancellation
Token refresh management
Analytics
Logging
Most production apps also include:
Axios interceptors
Request deduplication
Caching layers
API versioning
Realtime Systems Architecture
Realtime systems are among the hardest engineering problems in mobile apps.
Chat Systems
Apps like WhatsApp need:
Instant delivery
Read receipts
Typing indicators
Sync reliability
Message ordering
Architecture often includes:
WebSockets
Event queues
Local persistence
Retry systems
Live Updates
Apps like Instagram rely heavily on realtime engagement updates:
Likes
Comments
Notifications
Stories
Live streams
One major challenge is preventing unnecessary rerenders.
Ride Tracking
Uber-style tracking requires:
High-frequency location updates
Battery optimization
Background processing
Precision mapping
Realtime location systems are computationally expensive and difficult to optimize.
Offline-First Support & Caching
Modern apps cannot assume stable internet connectivity.
Offline-first systems often include:
Local databases
Mutation queues
Cache hydration
Background synchronization
Tools commonly used:
SQLite
MMKV
AsyncStorage
React Query persistence
Critical principle:
The app should still feel functional without internet.
App Startup Optimization Techniques
Startup performance heavily affects user retention.
Large apps optimize:
Bundle size
Font loading
Image loading
Navigation initialization
API hydration
Common techniques include:
Code splitting
Lazy loading
Route-level loading
Deferred rendering
Skeleton UIs
Apps like Netflix obsess over startup performance because milliseconds directly impact engagement.
Performance Considerations in Production Apps
Production apps continuously optimize performance.
Key focus areas include:
JS thread usage
Memory leaks
Re-render prevention
Image optimization
List virtualization
Background task efficiency
Common tools:
FlashList
Reanimated
Hermes
Memoization
Profiling tools
Performance engineering becomes an entire discipline at scale.
Shared Layouts & Nested Routing in Expo Router
Expo Router layouts are one of its biggest strengths.
Example:
app/
├── (tabs)/
│ ├── _layout.tsx
│ ├── home.tsx
│ └── profile.tsx
Shared layouts allow:
Persistent tab bars
Shared headers
Nested navigation
Feature isolation
This becomes extremely important in large multi-team applications.
Scalability Challenges in Apps Like Instagram, WhatsApp, Uber & Netflix
Every large-scale app faces different scalability challenges.
Massive media delivery
Feed ranking systems
Infinite scrolling performance
Realtime engagement updates
Reliable message delivery
Encryption
Offline synchronization
Multi-device consistency
Uber
Live GPS streaming
Dynamic pricing systems
Real-time trip updates
Battery optimization
Netflix
Video delivery optimization
Content recommendation systems
Streaming quality adaptation
Smart caching systems
Each app solves very different engineering problems despite sharing the same mobile platform.
Tradeoffs & Architectural Decisions at Scale
There is no perfect architecture.
Every decision introduces tradeoffs.
| Decision | Benefit | Cost |
|---|---|---|
| More caching | Faster UX | Stale data |
| Realtime systems | Better engagement | Complexity |
| Offline support | Reliability | Sync challenges |
| Modular features | Team scalability | More abstraction |
| Aggressive optimization | Better performance | Harder debugging |
Engineering at scale is mostly about choosing acceptable tradeoffs.
Final Thoughts
Modern apps like Instagram, WhatsApp, Uber, and Netflix are not just React Native projects with many screens.
They are distributed systems running inside mobile devices.
Using Expo Router today provides:
Cleaner navigation architecture
Better scalability
Feature modularity
Easier route management
Improved developer experience
Better team organization
But architecture alone is not enough.
The real challenge is designing systems that remain:
Fast
Reliable
Maintainable
Realtime
Offline-capable
Scalable
…even as millions of users interact with them simultaneously.
That is what separates production-scale mobile engineering from simply building apps.
