Engineering Products That Survive Contact With Reality: Patterns for Modern Digital Systems

Modernisation Is Not Rewriting Everything

The most expensive modernisation projects fail not because the technology was wrong, but because the scope was too ambitious. Replacing a 15-year-old monolith in 18 months is a project destined to ship 6 months late, over budget, with legacy defects ported faithfully into the new system.

The alternative is strangler fig migration: identify the highest-value, highest-pain surface area; carve it out into a modern service; route traffic progressively; retire the legacy piece only when the new path is stable. Repeat. This approach ships value every quarter rather than betting the business on a big-bang cutover.

The strangler pattern works because it embraces coexistence. Legacy and modern systems run in parallel, allowing rollback at every stage. The risk profile is fundamentally different from a full rewrite.

Cloud-Native Architecture: What It Actually Means in Practice

"Cloud-native" has been so over-used that it has almost lost meaning. In practice it means four things:

Elastic scaling: the system handles 10× normal load without manual intervention, and returns to baseline without wasting money. This requires stateless services, externalised session state, and auto-scaling policies calibrated to real traffic patterns — not theoretical peaks.

Fault isolation: a failure in one service does not cascade. Circuit breakers, bulkheads, and timeout contracts between services are not optional extras — they are the difference between a degraded experience and a full outage.

Infrastructure as code: every environment — dev, staging, production — is reproducible from code. No snowflake servers. No manual steps. No "we did it differently this one time."

Observability by default: structured logs, distributed traces, and metrics are first-class outputs of every service — not bolted on after the fact. If you cannot answer "what did this service do between 14:23 and 14:27 last Tuesday?" in under five minutes, your observability is incomplete.

API Design: The Contract That Outlives the Code

APIs are long-lived. The implementation changes; the contract endures. Poor API design becomes technical debt that compounds across every consumer — internal teams, mobile clients, third-party integrations.

Good API design starts with the consumer's mental model, not the database schema. REST, GraphQL, and gRPC are all valid choices — the decision should be driven by access patterns and consumer diversity, not team preference. REST wins for simple CRUD with broad tooling compatibility. GraphQL wins when consumers need flexible field selection across related entities. gRPC wins for high-throughput, low-latency service-to-service communication.

Versioning is non-negotiable. Every external API must have a versioning strategy before it ships — not added retroactively when a breaking change is unavoidable.

Mobile and QA: The Last Mile That Defines the Experience

Mobile is not a smaller version of your web product. It has different network conditions, different interaction models, different memory constraints, and different user expectations. React Native and Flutter have made cross-platform development economical, but they require platform-aware design — gestures, keyboard avoidance, deep linking, and push notification handling all require mobile-specific engineering.

Quality assurance at modern cadences cannot be purely manual. A good QA strategy layers unit tests (fast, isolated, run on every commit), integration tests (slower, catch contract failures between services), end-to-end tests (slowest, cover critical user journeys), and exploratory testing (human judgment, finds what automation misses). The goal is not 100% coverage — it is confidence at each release gate.