Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
48 results for “UI Monorepo Strategy”
Build Graph Scoping
Determining which packages a change actually affects, so a monorepo builds and tests a subset rather than everything on every commit.
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.
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.
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.
Server State Versus UI State
The distinction between data owned elsewhere and cached locally, and state that exists only in this session — conflating them causes most client state bugs.
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.
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.
Environment Ladder
The ordered set of environments a change climbs, where each rung is justified by a distinct claim it can prove that the one below cannot.
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.
Hexagonal Architecture
Putting the domain at the centre and letting everything external — UI, database, queues — attach through ports implemented by replaceable adapters.
Multi-Cloud
Deliberately running across more than one cloud provider — a decision with a much higher cost than the lock-in it is usually adopted to avoid.
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.
Over-Fetching
Transferring fields the interface will not display, which costs bandwidth and parse time on exactly the devices least able to afford them.
Query Plan
The database's chosen strategy for executing a query, and the first thing to look at when one is slow.
Recovery Point Objective
The maximum acceptable data loss measured as a duration, determining the replication and backup strategy.
Six Rs of Migration
The standard menu of options for each application in a migration — rehost, replatform, refactor, repurchase, retire, retain.
Slowly Changing Dimension
A strategy for handling attributes that change over time, deciding whether history is preserved and how facts attach to the correct version.
Testability as a Design Property
How cheaply a system's behaviour can be observed and controlled, which is decided by architecture and largely fixed before any test is written.
Time to Market
How long it takes to get a capability in front of customers — often the constraint that dominates every other architectural quality.
Twitter's Timeline Fan-Out
Twitter precomputes each user's timeline at write time but handles very-high-follower accounts at read time, because neither strategy alone survives both ends of the distribution.
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",
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
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
Leadership wants to consolidate a warehouse, a data lake and three departmental marts into a lakehouse. How do you scope and sequence this?
Establish the actual driver "Consolidate onto a lakehouse" is a solution. The driver is usually one of: cost of maintaining several copies, inconsistency betwee
Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?
Name the cost first The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" a
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
API Shapes for UI
REST, GraphQL and RPC judged by over-fetching, round trips and client coupling.
Container Image Strategy
Base images, layer hygiene, rebuild cadence, and patching a fleet of images.
Environment Strategy
How many environments earn their cost, what each proves, and what none of them prove.
Mobile Release Strategy
Store review, staged rollout, and supporting versions you can never force off.
Non-Functional Test Strategy
Testing availability, latency, security and recovery rather than only behaviour.
Test Architecture Strategy
Choosing what to verify where, given the failure modes that actually occur.
Client State Architecture
Server state, UI state and derived state, and why conflating them causes most bugs.
Enterprise Integration
Estate-wide integration strategy, standards and shared infrastructure.
Micro-Frontends
Independent deployment of UI slices, and the shared runtime that undermines it.
Testing & Quality Architecture
General material on designing a testing strategy as an architectural concern.