Mobile app backends look simple in the pitch deck and complicated in production. You need authentication, data sync, push notifications, file uploads, realtime events, payments, and analytics — all reliable across flaky mobile networks, hostile clients, and backgrounded apps that wake up once an hour to do everything at once. Getting the architecture right at the start saves thousands of engineering hours over the app's life.
This guide covers the backend patterns we use for mobile apps from MVP to multi-million-user scale. It's the architecture we actually ship, not a hypothetical reference model.
The Core Services Every Mobile Backend Needs
Identity and Authentication
Auth is the first thing the backend has to get right because it underpins everything else. Modern mobile auth stacks almost always include email/password, Apple Sign In (required by Apple for apps that offer other social logins), Google Sign In, and phone-number OTP. Passwordless magic links and passkeys are gaining share and worth building in from day one.
Managed identity providers (Auth0, Firebase Auth, Supabase Auth, Clerk) handle 90% of the complexity for most teams. Unless you have specific compliance or identity-federation requirements, avoid rolling your own.
Data API Layer
The data API is where most architecture debates happen. The three common shapes:
- REST: Well understood, easy to debug, cacheable at HTTP layer. Works fine for most apps. Over-fetching and chatty requests are the downsides.
- GraphQL: Clients fetch exactly what they need in a single request. Great for complex screens with multiple related entities. Server-side complexity and caching discipline are the costs.
- Realtime / subscription-first: Supabase, Firestore, Ably, and similar platforms push data as it changes. Best fit for collaborative or live-data apps (chat, dashboards, live sports, multiplayer).
Most production apps blend approaches: REST for simple CRUD, GraphQL for complex composite screens, and realtime for the handful of features that need it.
Push Notification Infrastructure
Push is deceptively complex. You need device-token management, topic-based routing, delivery-retry handling, and a way to respect platform quiet hours. Firebase Cloud Messaging (FCM) is the de facto standard and works across iOS (via APNs) and Android. Pair it with a queue (SQS, Pub/Sub, or Redis streams) so your API can enqueue notification sends without blocking the request path.
File and Media Handling
Mobile clients upload photos, videos, and documents constantly. Direct-to-S3 (or direct-to-GCS, direct-to-R2) with presigned URLs is the pattern that scales — your API hands the client a short-lived URL and the client uploads straight to object storage without round-tripping through your server.
Authentication Patterns That Work at Scale
Token rotation is the silent killer of mobile auth at scale. Short-lived access tokens (15-60 minutes) paired with long-lived refresh tokens is the standard, but the implementation details matter:
- Refresh tokens rotate on every use. A stolen refresh token is immediately invalidated when the legitimate client refreshes next.
- Access tokens are stored in memory only. Refresh tokens live in the iOS Keychain or Android Keystore — never in UserDefaults, SharedPreferences, or AsyncStorage.
- Background refresh handles the "app wakes up after 6 hours" case gracefully. Retry with exponential backoff and surface auth errors to the user only on explicit actions.
The Offline-First Pattern
Mobile apps run on flaky networks. Users expect the app to work on the subway, on a plane, and in the backyard where WiFi doesn't quite reach. An offline-first backend architecture accepts this reality.
Local-First Databases
The client holds a local copy of the data it needs and syncs changes in both directions. Libraries like WatermelonDB, Realm, and SQLite with a custom sync layer handle the read side. Dedicated sync engines (Supabase realtime, Electric SQL, PowerSync, Replicache) handle the harder write-merge logic.
Conflict Resolution
When two devices change the same record offline and then both sync, you have a conflict. The three common strategies:
- Last-write-wins: Simplest. The most recent timestamp wins. Works when conflicts are rare and non-critical.
- CRDTs: Conflict-free replicated data types merge automatically. Great for collaborative text and set-based data. Complex to implement from scratch; Yjs and Automerge are the leading libraries.
- Manual resolution: Surface the conflict to the user. Annoying but sometimes the only safe option for critical data.
The Read Path: Caching and CDN
Mobile clients are the worst-behaved HTTP clients in your stack. They reopen the app constantly, have aggressive refresh patterns, and hit the backend from 50 different countries with unpredictable latency. Caching is how you survive.
- CloudFront, Fastly, or Cloudflare in front of your API for static and cacheable responses.
- ETag and Last-Modified headers on GET endpoints so clients can send
If-None-Matchand save bandwidth on unchanged data. - Application-level caching (Redis, Memcached) for expensive queries. Budget 1-5 minutes TTL for most user-visible data.
Observability From Day One
You cannot fix what you cannot see. Mobile backend observability requires three layers:
- API metrics: Request rate, error rate, latency percentiles by endpoint. Datadog, Grafana Cloud, or similar.
- Client-side crash and performance: Sentry, Crashlytics, or Bugsnag. Tie crash reports back to the user and the specific app version.
- User funnel analytics: Amplitude, Mixpanel, or PostHog. Understand where users drop off and how feature adoption correlates with retention.
Scaling Transitions
The architecture that works for 10,000 users is not the architecture that works for 10 million. The transition points tend to hit at predictable scale milestones:
- ~100K users: Database read replicas. Caching layer. Queue-based background work.
- ~1M users: Service decomposition. Sharding or multi-region primaries. Dedicated realtime infrastructure.
- ~10M users: Event-driven architecture throughout. Per-feature service ownership. Advanced CDN and edge compute.
Frequently Asked Questions
Should I use a backend-as-a-service like Firebase or Supabase?
For most MVPs and apps under a few hundred thousand users, yes. BaaS platforms solve auth, storage, realtime, and data access with one SDK. You trade some architectural control for dramatically faster time-to-market. Teams that outgrow BaaS typically migrate specific high-volume features to custom services while keeping the platform for everything else.
REST or GraphQL for a mobile app?
Start with REST unless you have a specific reason to start with GraphQL. REST is simpler to debug, cache, and scale. Add GraphQL for complex aggregation screens once the need is clear.
How do I handle mobile app API versioning?
Version the API path (/v1/, /v2/) for breaking changes. For non-breaking changes, add optional fields to existing endpoints. Never remove or rename fields older clients rely on — you cannot force users to update.
Open Door Digital architects and builds scalable mobile backends. Talk to our team about your architecture needs.
Related reading: React Native Offline Sync Strategies and Mobile App Performance Optimization.