SaaS Platformsmoderate complexity

Mobile Backend Architecture

Backend architecture optimized for mobile applications with offline support, efficient sync, and push notifications across platforms.

Components

Considerations

Alternatives

moderate

Complexity

Fit

When this blueprint fits

And when to walk away from it

When to use this

You are shipping a mobile app where users expect the app to work on the train, on a plane, or in a basement. The backend needs to handle intermittent connectivity, conflict resolution, and device-specific delivery.

When NOT to use this

If your mobile app is essentially a thin client over a stable network connection (think internal tools on company wifi), a vanilla REST API is enough.

Architecture

System components

Key building blocks of this architecture, layered from infrastructure up.

API Layer

Mobile-optimised API with batching, persisted queries, and minimal payloads. GraphQL shines here because clients fetch exactly the fields they need across slow networks. If you stay with REST, design endpoints around screens not resources. See REST vs GraphQL.

GraphQLDataLoaderPersisted QueriestRPC

Push Notifications

Cross-platform push delivery with topic targeting, scheduled sends, and delivery analytics. FCM handles Android and APNs handles iOS, but the abstraction layer is yours: a single send API per user with channel preferences and quiet hours. OneSignal saves time if marketing wants self-serve campaigns.

FCMAPNsOneSignalExpo Push

Sync Engine

Delta sync with conflict resolution and bounded payloads. Mobile sync is the hardest correctness problem on this list. I lean on libraries like WatermelonDB or Realm for local-first storage and roll a server delta endpoint that returns changes since a client cursor. See the local-first sync lab.

Sync ProtocolWatermelonDBRealmVector Clocks

Media CDN

Image and video delivery with device-specific formats, adaptive bitrate, and offline caching hints. Mobile bandwidth is precious; serve WebP or AVIF, request the smallest size needed for the device, and let the client cache aggressively.

CloudinaryimgixHLSWebP/AVIF

Analytics and Crash Reporting

Event tracking, crash reports, and per-device performance metrics. Sentry plus a product analytics tool (Mixpanel, PostHog, Amplitude) covers most teams. Tag events with app version and OS version so regressions are easy to spot.

SentryMixpanelPostHogFirebase Crashlytics

Authentication

OAuth, biometric, and refresh-token flows that survive long sessions and device handoffs. Native biometric prompts (Face ID, fingerprint) feel modern but the server flow still uses standard OAuth. Plan for token revocation on device loss and silent refresh in the background.

OAuth 2.0PKCEBiometric APIsRefresh Tokens

Feature Flags

Remote configuration to ship dark launches, gradual rollouts, and emergency kill switches without app store delays. Mobile cannot revert a bad release the way web can. Wrap every risky path in a flag.

LaunchDarklyStatsigPostHog FlagsFirebase Remote Config

Planning

Critical considerations

The things I have learned the hard way and would not skip on the next build.

Design APIs for network efficiency. Batched requests, GraphQL field selection, and aggressive cache headers reduce battery drain and timeouts.

Implement robust offline handling with optimistic updates, conflict resolution, and a clear sync status in the UI. Users on the underground will judge your app by how it behaves disconnected.

Consider mobile-specific constraints from day one: battery, bandwidth, storage, background execution limits. Each platform has rules and they change every OS release.

Plan for the store-review cycle. Critical fixes can take 24 to 48 hours to land. Server-side feature flags and dynamic configuration are how you patch without a release.

See my mobile development service.

Options

Alternative approaches

Where I would consider a different shape entirely, with the trade-offs spelled out.

Alternative 01

Firebase for rapid mobile development with managed auth, database, and push. The fastest path to a prototype, with familiar trade-offs around vendor lock-in. See Supabase vs Firebase.

Alternative 02

Supabase as an open-source alternative when you want Postgres semantics and the option to self-host later.

Alternative 03

AWS Amplify for AWS-integrated mobile backends when your team already lives in AWS.

Alternative 04

Convex or Replicache for reactive sync-first backends when offline-first is a core feature, not an edge case.

Implementation

Related playbooks

Step-by-step guides for the harder parts of this architecture.

Securing Your API Endpoints

API security is not a sprinkle of middleware, it is a layered set of defenses where any one missing layer opens the door. This is my full checklist for hardening API endpoints: authentication, rate limiting, validation, CORS, audit logging, and the response headers that mitigate the long tail of browser-side attacks. Used on every production API I have shipped.

Read playbook

Production Monitoring & Observability

Observability is not three pillars on a slide, it is the difference between knowing why your system is misbehaving and guessing. This playbook is the monitoring stack I deploy on every production system: error tracking, structured logging, performance metrics, distributed tracing, and the dashboards and alerts that turn raw data into actionable signal without paging everyone at 3 AM.

Read playbook

In practice