Limited-time dealSupermicro HGX B200, 8 GPUs8-GPU NVIDIA HGX B200 server in stock
View the specification Call +91 92058 93902innovations@udhyamlabs.tech
Platform re-engineering
This practice replaces the parts of a system that can no longer carry the load or accept the changes the product needs. The system is designed to stay in service throughout, and your team keeps shipping outside the areas you agree to freeze. We separate what is still sound from what has to change, and the change is made one function at a time.
Rebuilding a system that has outgrown its original design
A system that was built correctly for one set of assumptions can stop coping when those assumptions change. We replace the parts that have to change, with the system designed to stay in service throughout. Traffic moves to a new path only after that path has matched the old one on the same live requests, within a tolerance agreed with you.
What the work is planned to deliver
- New components carrying production traffic
- Data migrated and verified as part of the project
- The old path retired, once the new path has met the retirement test agreed in advance
- Service decomposition
- Data model redesign
- Outbox and change data capture
- Backfill
- Traffic shifting
- Shadow comparison
The drawing shows requests divided between the old system and its replacements, with both answers compared before more traffic moves.
What the assessment examines, what you provide, and where the risk is
The assessment has a fixed fee and a fixed length, and it ends with written findings that are yours. You can stop there.
The assessment
We read the code, the data model and production telemetry. You receive a map of what is sound and what has to change, the order in which components can be extracted, and the cost of the period in which the old and the new must both run.
What you provide
You provide read-only access to the repositories and to production telemetry, the engineers who know why the system is the way it is, and a decision on which areas are frozen while they are being replaced.
Where the risk is
Data carries the risk. A request that moves money or calls a third party cannot simply be sent down two paths, and an application that writes to two datastores itself leaves them inconsistent when one of the writes fails.
How the work is done
Systems do not usually fail because they were badly built. They fail because they were built correctly for a set of assumptions that no longer holds: a tenth of the current traffic, a different read and write ratio, a data model that made sense before the second product line existed.
Wherever the system allows it we use the strangler fig pattern: new components are built beside the old system and take over its traffic one function at a time. The alternative, a full rewrite that runs for a year or more while the original keeps changing, is a common way for this kind of project to fail.
Before any traffic moves, the new path answers the same live requests as the old one and the two results are compared. For a request with side effects, the new path runs with its external effects switched off, and the comparison is made on the ledger entries and outbound messages it intended to produce. On paths that carry money the tolerance is zero unexplained differences. Elsewhere the tolerance is agreed with you in advance.
During the parallel run window each entity has one system of record. The application commits to that datastore in a single local transaction, an outbox table or change data capture carries the change to the other datastore, and a scheduled reconciliation reports any divergence. Reads move to the new datastore once its lag is inside the agreed bound. Write authority moves once, at a gate, and the stream is then reversed so that the old datastore remains a fallback until the old path is retired.
Each old path is retired once the new one has carried all of its traffic for an agreed period with no reconciliation break outside the agreed tolerance and no rollback. Where the system does not allow incremental replacement, for example a single shared database with no seam to cut along, the assessment says so and sets out the alternatives with their cost.
Questions about platform re-engineering
The Working with us page answers the rest. If yours is not there, ask it on the contact page and an engineer will reply.
You are a new firm. Why would we give you access to production?
You would not need to give us write access at the start. The assessment needs read access to sources that you choose, which can include production telemetry, and no ability to change anything. The analysis runs in a workspace that you create inside your own account, and where a source holds personal or cardholder data you can place a masked or aggregated export in that workspace. The assessment runs under an NDA and is carried out by engineers whose profiles you have seen. If you stop when it ends, you have spent the fixed fee and the cost of any capacity rented for the tests, and you hold findings that any other firm can act on.
What happens if your lead engineer leaves, or the firm stops trading?
A second engineer follows every engagement from the first day and can take it over. Everything we produce is committed to your repositories and runs in your accounts, and every decision is recorded there when it is made. You would hold the code, the configuration, the measurements and the decision record, which is what another team needs to continue.
How is the work priced?
The assessment has a fixed fee and a fixed length, and both are quoted before it starts. The price of the build is set out in the proposal that follows the assessment. We do not publish rates, because the fee follows the scope.
One team runs all five
Describe the problem, and an engineer will reply within one working day
Tell us in general terms what you are trying to do and what has stopped it. If it is not ours to take on, we will say so.