Mobile App Backend Development: Architecture, BaaS vs Custom, and Push Infrastructure [2026]

What users see in a mobile app is the surface. The backend is the foundation — handling authentication, data persistence, push notifications, real-time synchronization, and the business logic that makes the product work. Mobile app backend development is a distinct discipline from web backend development: mobile devices operate on variable networks, have battery constraints, and must handle offline states that web applications can ignore.

This guide covers the full technical decision surface of mobile app backend development: architecture patterns from monolith to serverless, the BaaS vs. custom backend decision, API design principles specific to mobile clients, push notification infrastructure, real-time synchronization patterns, and the scaling considerations that distinguish mobile backends from their web counterparts.

Mobile App Backend Development: Architecture Patterns

Monolithic Architecture for Mobile Backends

A single application containing all backend logic is the correct starting point for most mobile products. The operational simplicity of a monolith — single deployment unit, straightforward debugging, no inter-service networking — reduces the time to first working API from weeks to days.

The monolith scales to approximately 50,000 monthly active users on a well-configured managed server (2–4 vCPUs, 8–16GB RAM) with proper database indexing and caching. This covers most mobile products through the product-market fit phase without architectural changes.

When the monolith becomes constraining:

• When a specific backend function (push notifications, media processing, real-time messaging) has a performance profile incompatible with the rest of the application
• When team size exceeds 8–10 engineers and ownership boundaries become unclear
• When scaling requirements differ significantly across product areas

Microservices for Mobile Backends

Microservices decompose the backend into independent services that communicate via API calls or message queues. For a social mobile application, this might mean separate services for: user profiles and authentication, content feed generation, notification delivery, media processing, and search indexing.

The microservices architecture is operationally complex: service discovery, distributed tracing, inter-service authentication, and data consistency across service boundaries all require dedicated engineering effort. This overhead is justified when the team has the capacity to manage it and the product has the scale to require it.

Serverless Architecture for Mobile

AWS Lambda, Google Cloud Functions, and Cloudflare Workers execute discrete functions in response to API requests without requiring persistent server management. The advantages for mobile backends: automatic scaling to zero during off-peak periods (reducing cost), no server management overhead, and fine-grained scaling per function.

The limitations: cold start latency (100ms–2000ms for the first invocation after a period of inactivity) can create noticeable latency spikes in mobile applications; function execution time limits (15 minutes maximum on Lambda) constrain long-running operations; and vendor lock-in is more pronounced than with container-based deployment.

BaaS vs Custom Backend: Decision Framework

Backend-as-a-Service platforms provide pre-built backend infrastructure that mobile apps can connect to without writing server-side code. The three dominant options are Firebase, Supabase, and AWS Amplify.

Firebase

Firebase provides: Firestore (document database with real-time subscriptions), Firebase Authentication (email/password, OAuth, phone), Cloud Messaging (push notifications), Storage (file uploads), and Hosting.

Correct use case: Consumer mobile apps with real-time features (chat, collaborative tools, live feeds), team with limited backend engineering capacity, time-to-market under 3 months, expected initial scale under 50,000 monthly active users.

Limitations: Firestore's document model is a poor fit for relational data (transactions between multiple entities, complex reporting queries). Costs scale non-linearly — a Firestore-backed app with 1 million documents and 100,000 monthly users can generate $500–$2,000/month in read/write costs, which surprises teams that built on the free tier.

Vendor lock-in mitigation: Abstract Firebase calls behind a service layer from day one. This does not eliminate lock-in but makes migration feasible without rewriting the entire application.

Supabase

Supabase is an open-source Firebase alternative built on PostgreSQL. It provides: a PostgreSQL database with real-time subscriptions via websockets, row-level security (RLS) policies for data access control, authentication, and file storage.

Correct use case: Mobile apps that require relational data integrity, teams familiar with SQL, products where GDPR or data residency requirements favor a self-hostable option. The PostgreSQL foundation makes complex queries, reporting, and data migrations significantly more tractable than Firestore.

Limitation vs Firebase: Real-time subscription performance at high concurrency requires careful RLS policy design — poorly written policies generate full table scans on every subscription update.

AWS Amplify

AWS Amplify wraps AWS services (Cognito for authentication, AppSync for GraphQL API, DynamoDB or Aurora for data) in a developer-friendly SDK.

Correct use case: Organizations already running on AWS, teams that need enterprise-grade compliance features (SOC 2, HIPAA with BAA), products requiring DynamoDB's global distribution capabilities.

Limitation: Amplify's abstraction layer is opinionated and can make debugging underlying AWS service issues difficult. Teams should have AWS expertise before adopting Amplify for production systems.

Custom Backend: When BaaS Is Not Sufficient

A custom backend (Node.js, Go, Python, Java) is the right choice when:

• The product requires complex business logic that cannot be expressed in BaaS rules
• The data model is highly relational with strict integrity requirements
• Long-term cost optimization is a priority (BaaS costs more than managed cloud at scale)
• The team has backend engineering capacity
• Regulatory requirements mandate specific infrastructure controls

The custom backend development investment is 6–12 weeks for a competent team to build the equivalent of what Firebase provides out of the box. This investment makes sense when the product's differentiation comes from the backend logic, not from the standard features that BaaS platforms provide.

API Design for Mobile Clients

Mobile API design has specific requirements that differ from web API design:

Bandwidth Efficiency

Mobile clients operate on limited and variable bandwidth. API responses should:

• Include only the fields the client actually needs (use fields query parameters or GraphQL)
• Support pagination from the first release (unbounded list endpoints create performance problems when the data grows)
• Compress responses with gzip/brotli (typical 60–80% response size reduction)
• Cache aggressively on the client side (ETags or Last-Modified headers for conditional GETs)

Offline-First Design

Mobile users experience network interruption routinely. APIs should support:

• Conflict-free replicated data types (CRDTs) for collaborative features
• Optimistic updates on the client with server reconciliation
• Sync tokens for efficient incremental sync (client sends last-known sync state, server returns only changes since then)
• Idempotent mutations (POST requests that can be safely retried after network failure)

Authentication for Mobile

Mobile authentication differs from web authentication in one critical way: there is no secure cookie storage equivalent on mobile. JWT tokens stored in device keychain/keystore are the standard approach. Design considerations:

• Access tokens: Short-lived (15–60 minutes), stored in memory
• Refresh tokens: Longer-lived (30 days), stored in device keychain (iOS) or Android Keystore
• Token rotation: Issue new refresh token on every access token refresh (single-use refresh tokens prevent replay attacks)
• Biometric authentication: Use the device's biometric API (Face ID, fingerprint) to gate the keychain access, not to authenticate against your server

Push Notification Infrastructure

Push notifications are a core engagement mechanism for mobile apps. The infrastructure is more complex than sending a message — it involves token management, delivery tracking, payload design, and handling the edge cases that determine whether notifications feel valuable or intrusive.

The Push Notification Stack

App Backend → Firebase Cloud Messaging (FCM) / Apple Push Notification Service (APNs)
           → Device

FCM handles both Android and iOS push notifications (via Apple's APNs integration). Sending directly to APNs from a custom backend requires managing Apple certificates and private keys — most teams use FCM as a unified layer.

Token Lifecycle Management

Every device has a push token that identifies it to the notification service. Tokens change when: the user reinstalls the app, the app is restored on a new device, or the user revokes notification permissions.

Registration:

// React Native push token registration
import messaging from '@react-native-firebase/messaging';

const registerPushToken = async (userId) => {
  await messaging().requestPermission();
  const token = await messaging().getToken();

  // Store token server-side, associated with userId and device
  await api.post('/devices', {
    token,
    platform: Platform.OS,
    userId
  });
};

// Handle token refresh
messaging().onTokenRefresh(token => {
  api.patch('/devices/current', { token });
});

Server-side token invalidation: FCM returns specific error codes when a token is invalid or the app has been uninstalled. Handle these codes in the notification send response and remove invalid tokens immediately — sending to stale tokens inflates your registered device count and wastes API quota.

Notification Payload Design

Push notifications have hard size limits: APNs maximum payload is 4KB; FCM maximum is 4KB for data messages and 2KB for notification messages. Design notifications for scannability:

• Title: Action or status (5–7 words maximum)
• Body: Context that makes the action worth taking (1–2 sentences)
• Data payload: Include enough context for the app to deep-link directly to the relevant content (entity type, entity ID, action)

Notification Fatigue Prevention

Notification fatigue — users disabling notifications because they feel spammed — is the most common failure mode for mobile engagement strategies. Prevention mechanisms:

• User-controlled notification preferences at the category level (not all-or-nothing)
• Quiet hours (store user timezone, suppress non-critical notifications 10pm–8am local)
• Delivery analytics: Track open rates per notification category; categories with below 10% open rates should be reviewed for necessity
• Progressive notification reduction: Users who have not opened the app in 30 days should receive fewer notifications, not more

Real-Time Synchronization Patterns

Real-time features — live feeds, collaborative editing, presence indicators, chat — require a different data delivery model than REST API polling.

WebSocket Architecture

WebSockets maintain a persistent connection between the mobile client and the server, enabling server-push events without polling overhead.

When to use WebSockets:

• Chat or messaging features
• Collaborative editing (documents, whiteboards)
• Live presence (who is online, typing indicators)
• Real-time dashboards (live counters, feed updates)

Operational considerations: Each WebSocket connection consumes a file descriptor on the server. A Node.js server can handle approximately 10,000 concurrent WebSocket connections per vCPU (with proper configuration). At 50,000 concurrent users, horizontal scaling becomes necessary.

Server-Sent Events (SSE) for One-Directional Real-Time

For feeds and notifications where the server pushes data but the client does not need to send data via the same connection, Server-Sent Events are simpler than WebSockets: they use standard HTTP, are automatically reconnecting, and work through most corporate proxies.

Polling as a Fallback

For features where occasional latency is acceptable (notifications, non-critical feed updates), intelligent polling is simpler and more reliable than WebSockets. Use exponential backoff with jitter to prevent thundering herd problems when users return to the app simultaneously.

Scaling Mobile Backends

Mobile applications have traffic patterns that differ from web applications: usage spikes at morning commute time and evening relaxation windows, geographic concentration when the app is popular in specific markets, and burst patterns after a social media mention or press coverage.

Key scaling patterns:

Horizontal scaling with stateless application servers: Session state stored in Redis (not in-process) allows any application server to handle any request, enabling load balancer-driven horizontal scaling.

Database read replicas for read-heavy workloads: Mobile social feeds, user profiles, and content listings are typically 90%+ reads. Read replicas on PostgreSQL or MySQL offload read traffic from the primary database.

CDN for static assets and media: Profile images, content thumbnails, and static assets should be served from a CDN (CloudFront, Fastly). This reduces origin server load and significantly improves latency for geographically distributed users.

Rate limiting per user and per endpoint: Mobile clients can be misconfigured (infinite retry loops, polling at too-high frequency). Rate limiting at the API gateway layer prevents runaway clients from degrading service for all users.

Conclusion

Mobile app backend development is a set of specific decisions that differ meaningfully from general web backend engineering. The architecture choice (monolith vs. microservices vs. serverless), the BaaS vs. custom backend trade-off, API design for bandwidth-constrained clients, push notification infrastructure, and real-time synchronization patterns — each requires deliberate consideration specific to the mobile context.

The teams that build reliable mobile backends are not the ones with the most sophisticated architecture. They are the ones who matched architecture complexity to team capacity, made token management reliable from day one, designed APIs with mobile network constraints in mind, and scaled infrastructure in response to real growth rather than anticipated growth.

Start simple. Measure what constrains you. Scale the specific components that need it.