---
title: "Platform and transactional architecture"
publisher: "Data Nexus Technologies Services FZ-LLC"
canonical: https://www.datanexus.ae/services/platform-architecture
licence: "Quote freely with attribution to Data Nexus and a link to the canonical URL."
---

# Platform and transactional architecture

Most platforms do not fail at the interface. They fail because the transaction was never modelled — so every new requirement adds a branch, and the branches eventually contradict each other.

**What we hold fixed.** The domain model is the product. Everything above it is an interface to it.

## When this is the problem

- A feature that should take days takes a sprint, and nobody can say why.
- The same order can be in two states at once, depending on which screen you ask.
- The platform is fine until the campaign lands, and then it is not.
- Two products were merged and now share a schema neither of them fits.

## The work

**Transaction and state modelling.** We write down the states an order, an account or a booking can legally occupy, and the transitions between them. Most of the defects in a mature platform live in the transitions nobody named.

**Domain invariants before features.** What must remain true regardless of release — balances that reconcile, bookings that cannot overlap, prices that cannot be negative. These become constraints in the system rather than conventions in a document.

**Consistency and failure isolation.** Where the system must be strongly consistent and where it can settle later, which failures may propagate and which must be contained, and what the platform is allowed to do when a dependency is down.

**Behaviour under load.** Load is a design input, not a later optimisation. Which paths must stay fast when the rest queues, where the limits sit and who they apply to, what is cached and what may never be, and which features are isolated so that the busiest one cannot take the others down with it. We build this into our own products — the group that fails is one group, never the platform.

**Unifying several products on one core.** Companies that ship three products usually maintain three half-domains. We define the shared core and the seams, so the products stay separate where they differ and stop diverging where they do not.

## What you receive

- A state and transaction model of the domain, written so a non-engineer can argue with it
- An architecture definition: boundaries, contracts, consistency and failure behaviour
- A migration path from the system you have to the one described, in shippable stages
- The invariants, expressed as constraints and tests rather than as documentation

## Questions

**Do you rewrite the platform?**

Rarely, and never as an opening move. A rewrite is the most expensive way to discover that the original model was the problem. We model first, correct the model in place where that is possible, and reserve replacement for the components that cannot be corrected.

**How long does an architecture engagement take?**

The definition itself is usually four to eight weeks depending on the number of products involved. Implementation runs longer and is staged so that value lands before the last stage.

**Do you work with our existing engineering team?**

That is the normal case. We operate close to the CTO and the core team; the architecture has to be something they can carry after we leave, or it was theatre.

## Related

- [Custom software development](https://www.datanexus.ae/services/custom-development)
- [Anti-crisis recovery](https://www.datanexus.ae/services/anti-crisis-recovery)
- [Decision intelligence](https://www.datanexus.ae/services/decision-intelligence)

---

Canonical version: https://www.datanexus.ae/services/platform-architecture