Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Mobile Release Strategy”
Forced Upgrade
Blocking an installed client version from operating until it updates, which is the only lever available and is disruptive enough to need a policy.
Non-Functional Acceptance
Treating quality-attribute targets as acceptance criteria with automated verification, so a release can fail on latency the way it fails on a broken feature.
Attribute History Strategy
The per-attribute decision about whether history is overwritten, versioned or kept alongside the current value, which is a business question rather than a technical one.
Automated Release Verification
A gate that compares the new version's live signals against the old one's and decides, on stated criteria, whether to continue or revert.
Backup Strategy
A plan for what is copied, how often, where to, how long it is kept, and — the part that decides whether it is real — how the restore is verified.
Caching Strategy
The chosen pattern for how a cache is populated, read and invalidated — cache-aside, read-through, write-through or write-behind.
Canary Release
Routing a small fraction of traffic to a new version, watching its metrics, and expanding or rolling back based on what they show.
Chunk Boundary Strategy
How source documents are split for embedding, which determines whether retrieved passages are self-contained and coherent.
Database Migration Strategy
The approach for moving data to a new store, which is usually the longest pole and the highest risk in any modernisation.
Fallback Strategy
What a caller does instead when a circuit breaker is open — the part of the pattern that determines whether failing fast helps anyone.
Indexing Strategy
Choosing the set of indexes a table carries by working backwards from its actual queries, and accepting the write cost that each one adds.
Release Ring
An ordered cohort of users a change reaches before the next one, chosen so that early rings would notice a fault and tolerate it.
Subject Naming Strategy
How schemas are keyed in a registry — per topic, per record type, or both — which determines whether one topic may carry several event types.
Tagging Strategy
A defined, enforced set of metadata labels applied to every resource, without which cost allocation, ownership and lifecycle automation are all impossible.
Test Strategy Altitude
Deciding which risks are verified at which level, so that each layer tests something the layers below it structurally cannot.
Testing Strategy Shape
The distribution of tests across levels, chosen so that feedback is fast where it can be and confidence is real where it must be.
Architecture Review Board
A forum that reviews significant designs against standards, risks and strategy before commitment.
Base Image Currency
How far behind the fleet's running images are from their patched base, which is the number that decides how fast a critical vulnerability can be closed.
Blue-Green Database Schema
The constraint that makes fast rollback actually work — both application versions must be able to run against one schema at the same time.
Blue-Green Deployment
Running two identical production environments and switching traffic from the old one to the new one in a single cut, with the old kept warm for rollback.
Build Graph Scoping
Determining which packages a change actually affects, so a monorepo builds and tests a subset rather than everything on every commit.
Business Capability
What a business does, expressed stably and independently of how it currently does it or who is responsible.
Capability Map
A structured view of everything a business does, used as the stable frame for mapping applications, investment, ownership and gaps.
A platform of 40 services has logs only, and incidents take hours to diagnose. Design the observability strategy and its rollout order.
Why logs alone fail at this size Logs answer "what happened in this service". They cannot answer "where did this request spend its time across twelve services",
A release must rename a heavily used database column and ships tonight. The team proposes doing the rename in the deployment. What is wrong, and what do you propose?
What is wrong A rename is not additive. During a rolling deployment both versions of the application run simultaneously: one expects the old name, one the new.
An executive says "we need an AI strategy" and asks you to come back in two weeks. How do you handle the ambiguity?
Do not go away and produce a strategy document A document answering a question nobody has articulated will be received politely and shelved. The brief is ambigu
Mobile conversion is 40% below desktop. Product blames the design; analytics shows users leaving before the page is usable. How do you investigate?
Get field data before touching anything A laboratory run on a developer machine measures one configuration, usually the fastest one anyone uses. Real traffic in
Production is degraded after a release. The team tries to roll back and discovers a migration has already run. What do you do now, and what do you change afterwards?
Now: stop trying to roll back Reverting the deployment would run the previous code against a schema it does not know, which is a second and less understood fail
You are designing APIs for a platform with a web app, a mobile app, internal service-to-service traffic and third-party partners. What do you expose, and where?
What the interviewer is testing Whether you choose per constraint or adopt one technology as an identity. The wrong answers here are all defensible sounding and
You migrate a mobile API to HTTP/2 and p99 latency gets worse for users on cellular networks, while p50 improves. Explain and decide what to do.
The mechanism TCP head of line blocking. HTTP/2 multiplexes all streams onto one TCP connection. TCP guarantees ordered delivery, so a single lost packet stalls
You need to ship a rewrite of the pricing engine. Same inputs, same expected outputs, completely new implementation. How do you release it?
What the interviewer is testing Whether you know that release strategy is part of architecture, and whether you reach for verification techniques beyond "test i
A new platform must serve a public partner API, three internal front-ends with different data needs, and high-volume service-to-service traffic. Choose the API styles and defend the choice.
Resist "pick one" These are three different problems with three different consumers. Standardising on one style optimises for architectural tidiness at the expe
An end-to-end suite of 340 tests takes four hours and fails spuriously about half the time. The team wants to parallelise it. Is that the right move?
Parallelising treats the symptom It might halve the runtime. It will not touch the flakiness — in fact parallelisation often worsens it, by exposing shared stat
Mobile Release Strategy
Store review, staged rollout, and supporting versions you can never force off.
Environment Strategy
How many environments earn their cost, what each proves, and what none of them prove.
Container Image Strategy
Base images, layer hygiene, rebuild cadence, and patching a fleet of images.
Delivery & Release Engineering
General material on getting a change from commit to production safely and often.
Edge, Mobile & IoT
General material on architecture beyond the data centre boundary.
Mobile App Architecture
Layering, navigation, background execution, and the platform rules you do not set.
Non-Functional Test Strategy
Testing availability, latency, security and recovery rather than only behaviour.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Test Architecture Strategy
Choosing what to verify where, given the failure modes that actually occur.
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
Artifact Management
Immutable versioned outputs, promotion between repositories, and retention policy.
Branching Models
GitFlow, trunk and release branches as delivery constraints rather than Git preferences.
Build Reproducibility
Pinned inputs and hermetic builds, so one commit cannot produce two different artifacts.
CRDTs
Data types that converge without coordination, and the semantics you must accept.
Change Management vs CD
Reconciling CAB-era controls with continuous delivery without pretending either away.
Constrained Protocols
MQTT, CoAP and their kin, chosen for power, packet size and intermittent links.
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.
Database Migration Under CD
Expand-contract, backwards-compatible schema change, and migrations that cannot roll back.
Deployment Gates
Automated verification between stages, and the difference between a gate and a delay.
Deployment Strategies
Rolling, blue-green, canary and shadow, and the traffic and state each one assumes.
Device Identity
Identifying a thing rather than a person, and rotating a credential you cannot type.
Device Provisioning
Getting identity and configuration onto hardware at manufacture or first boot.
Device Telemetry at Scale
Deciding what a device sends, how often, and what is aggregated before it leaves.
Digital Twin
A server-side model of a physical thing's reported and desired state.
Edge Compute Topologies
Regional, metro, on-premises and on-device, and what each tier is genuinely for.