Backend, frontend, mobile, data, and ML systems demand the same engineering maturity, but they begin from very different constraints and recurring sources of failure.
This chapter shows how the same architecture conversation changes across domains: sometimes latency and scale dominate, sometimes client lifecycle and interface behavior, and sometimes data movement, feature quality, or model release mechanics.
For preparation, that matters because it keeps you from forcing one template onto every role and helps you see in advance which track you are likely to face and where your profile needs more depth.
Practical value of this chapter
Domain Constraints
Compare which constraints actually shape the answer in each track: network, interface, data, model, or infrastructure.
NFR Priorities
Decide early which non-functional requirements dominate in your domain and which ones stay secondary.
Ownership Boundaries
Clarify who owns the interface, data, client, and infrastructure so the design stays executable for a real team.
Approach Adaptation
Show how the same architecture scaffold changes across tracks without turning into one generic answer template.
A system design round for a backend engineer and a similar round for a frontend, mobile, data, or ML specialist only look alike from a distance. The same architectural maturity is expected in every case, but the constraints, recurring failures, and signs of a strong answer change with the domain.
How common these tracks are
This is a directional market picture, not precise industry statistics. The point is to show which tracks appear most often and which domain assumptions are worth preparing for in advance.
Foundation
HTTP protocol
A core protocol behind a large share of external APIs and server-side integrations.
Backend and server systems
Core backend track
The backend round remains the baseline shape of architecture interviewing. It favors strong reasoning about distributed services, scaling, reliability, and how the system behaves under real load.
Key components
- Load balancers
- SQL and NoSQL databases
- Caches such as Redis and Memcached
- Queues and streams like Kafka and SQS
- CDN and API Gateway
Typical tasks
What gets assessed
Scaling, availability, and the cost of different consistency modes.
NFR focus
Latency, throughput, and fault tolerance.
Deep dive
Sharding, replication, caching, and CAP theorem.
Frontend and client web
Web client architecture
The frontend track centers on client architecture boundaries, rendering performance, state handling, and accessibility. If server rendering is involved, hydration usually becomes part of the conversation as well, because it directly affects responsiveness and the user path.
RADIO framework
Key topics
- Component architecture and modularity
- State management with Redux, Context, or Zustand
- SSR, CSR, and SSG with hydration
- Performance metrics: LCP, FID, CLS
- Code splitting and lazy loading
Typical tasks
Optimizations
List virtualization, progressive image loading, debouncing, and bundle-size work.
How it differs from backend
Less infrastructure and database reasoning, more attention to interface behavior, browser constraints, and the user path.
Foundation
Android: mobile OS
Mobile OS constraints that shape how a client application is designed and maintained.
Mobile and on-device applications
iOS and Android application architecture
Mobile interviews quickly shift toward lifecycle constraints, unstable networks, battery and memory limits, and offline-first behavior. Strong answers show how the app remains useful without perfect connectivity and how local state is reconciled with the server.
Local-first operation
A local database becomes the main state holder, while synchronization runs in the background through repository patterns and remote mediators.
Battery and memory
Economical use of background work, images, memory, and network under device limits.
Sync strategies
Push notifications, WebSockets, SSE, and conflict resolution between local and server-side changes.
Architectural patterns
Typical tasks
What makes the mobile track special
Data and data platforms
Data platforms and pipelines
The data track revolves around the path data takes: from sources and transforms to analytical stores and downstream consumers. That naturally leads to conversations about stream processing, data lakes, data warehouses, and the balance between delay, quality, and cost.
Data journey — 5 layers
Sources
Processing
Storage
ML/AI
Consumers
Key concepts
Spark and Airflow versus Kafka and Flink: the difference is mainly in delay profile and delivery model.
Whether schema is enforced before loading or inside the analytical platform.
Incremental change delivery from transactional systems into analytics and downstream services.
Medallion architecture
Raw, immutable data
Cleaned and validated datasets
Business-ready aggregates and serving tables
Technology stack
Typical tasks
ML and model-driven systems
MLOps and model inference
The ML track adds feature stores, inference paths, model serving, and drift monitoring to the usual backend conversation. A strong answer has to cover not only service architecture, but also discipline around data quality and model releases.
Good answers almost always touch training-serving skew, versioning of features and models, and lineage, because without those pieces it becomes hard to debug errors and regressions in production.
ML pipeline architecture
Data ingestion
Feature store
Training
Model registry
Inference
Feature store
A central place for features used in both training and production. It helps keep the same feature logic between experiments and live traffic.
For batch training
For real-time inference
Inference path
Release strategies
- Canary rollout
- A/B testing
- Shadow deployment
- Blue-Green
Monitoring
- Data drift detection
- Model quality: P/R/AUC
- Latency and throughput
- Feature distribution
Typical tasks
Key question in the ML track
“How do you keep features consistent between training and production?” Strong answers usually rely on a feature store, shared feature computation, versioning, and an auditable history of where the data came from.
Comparing the tracks
| Aspect | Backend | Frontend | Mobile | Data | ML |
|---|---|---|---|---|---|
| Primary focus | Service scaling | UX and rendering | Offline use and device limits | Data movement and quality | Model lifecycle |
| NFR priority | Latency, throughput | LCP, FID, CLS | Battery, memory | Freshness, accuracy | Accuracy, latency |
| Main state | DB and cache | Client state | Local DB and sync | Lake and warehouse | Feature store |
| Working framework | Alex Xu’s 4-step model | RADIO | MVVM + Repository | 5-layer data journey | ML pipeline |
| Typical duration | 45-60 min | 45 min | 45 min | 45-60 min | 45-60 min |
Key takeaways
Backend is still the default reference point, but it no longer represents the full space of architecture interviews.
Frontend shifts the conversation toward interface architecture, rendering, client state, and the user path.
Mobile tests whether you can design for bad networks, battery limits, memory pressure, and autonomous local behavior.
Data focuses on data movement, processing layers, and the balance between quality, delay, and cost.
ML adds models, features, release mechanics, and post-release quality monitoring to the architecture discussion.
Clarify the domain track — ask the recruiter in advance which version of the architecture round is expected for your role.
Related chapters
- How the system design approaches section is structured - gives a map of the section and explains why domain-specific interview tracks should not be treated as one generic category.
- System Design Interview Frameworks - shows the baseline conversation structure that later needs to be adapted for backend, frontend, mobile, data, and ML.
- System Design Interviews: A 7-Step Approach - explains how the same interview framework changes depth and priorities depending on the domain.
- Why frontend architecture matters for system design - deepens the frontend track: client architecture, rendering performance, interface state, and browser constraints.
- Android: mobile OS - adds platform context for mobile interviews: OS constraints, application lifecycle, and device behavior under load.
- Database selection framework - helps defend storage choices in backend and data rounds based on access shape, workload, and data requirements.
- Machine learning system design interview (short summary) - maps the general architecture approach to ML: features, inference paths, and production risks.
- Observability and monitoring design - extends any domain track with metrics, logs, traces, and alerting practices.