Altitude

Move beyond features. Think in systems.

At senior level, your mobile depth is the thing. At staff level, the expectation changes: you need to understand how the client fits into the complete system.

Staff mobile systems engineering is its own discipline

It is not backend engineering with a phone attached, and it is not senior mobile work with a bigger title.

A mobile client is a node in a distributed system that you do not control. It runs on hardware you did not choose, on networks that drop mid-request, on OS versions that lag by years, with users who force-quit at the worst moment. Backend playbooks assume you can deploy a fix in minutes. On mobile, your worst bug ships in a binary that some users will keep for eighteen months.

That constraint changes every architectural decision above it. API versioning stops being hygiene and becomes survival: every endpoint you change must keep working for every binary still in the field. Caching stops being an optimization and becomes the difference between an app that works in the subway and one that does not. Authentication has to survive token expiry on a device that has been offline for a week. Observability has to work when the crash report is the only witness and it arrives three days late.

I have sat in architecture reviews where strong backend engineers proposed designs that were correct for services and unshippable for clients. I have also watched senior mobile engineers freeze when the conversation moved past the app boundary into contracts, queues, and failure budgets. The staff mobile role sits exactly on that seam, and almost nothing is written about it. The system design canon is server-side. The mobile canon stops at the app's edge. Altitude covers the seam: how the client, the BFF, the backend, and the organization around them behave as one system, and how to make decisions that hold up on both sides of it.

How the book teaches

Patterns are cheap. Judgment is the product. Every chapter is built to transfer the second one.

Each part opens with the decision you will actually face: the API is changing, the sync engine is corrupting data, the security review found the token in logs. The pattern comes after the problem, with the trade-offs stated plainly: what it costs, when it breaks, and what the alternative would have cost instead. Where a decision is contested, the book shows the ADR: the options considered, the one chosen, and the reasoning a staff engineer would be expected to defend in review.

The last part is three complete case studies: a ride-hailing platform, a global messaging system, and a high-assurance financial product. Each one runs the full loop from requirements through architecture to a production incident and its postmortem. They exist because the hardest part of systems work is not knowing the patterns. It is recognizing which one the situation in front of you is actually asking for.

If you are preparing for a mobile system design interview specifically, this is not that book. Altitude is about doing the work, not performing it in 45 minutes. The interview version of this material lives in Mobile System Design Blueprint. The full catalog is at salari.dev/books.