Data platform · Data integration
Data integration services in Saudi Arabia: keep data in step between systems that were never built to share it
Data integration keeps the same data correct in several systems that all keep running: a core application and its reporting database, two platforms that share customer records, a legacy database and the new one being built beside it. Interkey provides data integration services in Saudi Arabia with two things it runs itself: iblync, its own platform for real-time replication between systems that do not match, and a system integration practice for interfaces where one system calls another. Every interface gets a written contract, tests with real data, and a named owner after go-live.
Published 5 min read
In short
- Records or requests? If records must be copied and kept in step, that is replication. If one system must ask another to do something, that is an API. Scheduled bulk exchange is files and batches.
- iblync: continuous real-time replication, including two-way synchronisation where both sides accept writes; changes queue when the target is down; throttling protects production.
- Connectors: a connector set that is actively extended, with custom connectors built for systems it does not yet cover.
- Method: an inventory of interfaces, a contract per interface, tests with real data shapes, and cutover one interface at a time.
- After go-live: monitored for volume, failures and staleness, with a named owner per interface; Interkey can operate it.
- Pricing: iblync is quoted per source system, target system and data volume.
What data integration is, and what it is not
Data integration is ongoing. It runs for as long as the connected systems run, and it fails quietly when nobody watches it. A data migration is different: it ends when the old system is switched off. Many projects need both, because a migration without downtime usually keeps the old and new systems in step for a while before cutover. Our database migration guide covers that case.
Relateddatabase migration guide
Records or requests: choosing the integration pattern
| What has to happen | Pattern that usually fits | How Interkey delivers it |
|---|---|---|
| The same records must exist, current, in two or more systems | Continuous replication | iblync |
| One system must ask another to do something, such as check a customer or create an order | API layer through a governed gateway | API management practice, on Kong |
| Several systems need to react promptly to the same change | Event streaming | System integration practice |
| Data is needed daily or weekly for reconciliation or reports | Files and batches | System integration practice |
| Two systems share one flow with one owner, and that will not multiply | Point to point | System integration practice |
The pattern is chosen per interface, not per estate. An estate usually ends up with several of them, and the system integration practice explains each one in more depth.
Real-time replication with iblync
iblync is Interkey's own platform for data migration and replication, built in Saudi Arabia, for systems that were not designed to exchange data.
- Continuous real-time replication, including bi-directional synchronisation where both sides accept writes. What happens to a record changed in both places is settled as a design decision before go-live.
- Queueing when the target is down. Changes are held and moved when the target returns, instead of failing.
- Throttling and resource control, so replication does not compete with production for capacity.
- Configured workflows rather than hand-written scripts, so your own database team can see, review and repeat what the integration does.
- Connectors that are actively extended, with custom connectors built for systems iblync does not yet cover.
Read more
iblync is usually the wrong tool when both systems come from one vendor that already offers a supported native path between them. That path tends to be cheaper and better supported, so use it. Where iblync runs, and whether data leaves your environment, is settled for each project before anything moves.
Questions to settle before any data moves
- Ownership: which system is the source of truth for each entity and field?
- Direction: one-way, or two-way? If two-way, what happens to a record changed in both places at once?
- Freshness: must the copy be current within seconds, minutes, or by the next morning?
- Capture: how does each source system expose its changes, and what load does that put on it?
- Shape: how do the source and target data models differ, and what has to be transformed?
- Failure: what happens when the target is unavailable, and who is told?
- Location: where does the integration run, and may the data leave your environment or the Kingdom?
- Ownership after go-live: who watches each interface and who fixes it?
How Interkey delivers data integration services
-
Inventory and ownership.
List the interfaces that exist and the ones that are needed, with an owner and a consumer for each, and agree what the shared data means.
-
Contract per interface.
Payloads, frequency, failure handling and change notice, written before anything is built. The contract becomes the test baseline.
-
Build and test against the contract.
Tests use realistic data, including malformed records, Arabic text, mixed scripts and legacy encodings.
-
Cut over one interface at a time.
Each new interface runs in parallel with the old one until the outputs agree, then switches. During parallel running, switching back stays possible.
-
Operate and watch.
Volume, failures and staleness are monitored, the owner is alerted, and the inventory stays current. Interkey can run this as a managed service from Riyadh.
When the data must stay in the Kingdom
Residency often decides the design before features do. Workloads whose data must stay in the Kingdom point to self-managed platforms on infrastructure you control. The same applies to the integration layer itself: decide where the replication engine, the gateway and any message broker run, and record that decision in each interface contract.
Questions buyers ask
Do we need iblync for every integration?
No. iblync is for keeping records in step. Request-and-response interfaces belong in an API layer, and daily reconciliations often work better as files and batches.
Can iblync keep two databases in step in both directions?
Yes. Bi-directional synchronisation is supported where both sides accept writes. The rule for records changed in both places is designed before go-live.
Which databases and systems does iblync connect?
The connector set is actively extended, and custom connectors are built for systems it does not yet cover. Name your source and target systems in the first conversation and we will confirm the route.
Will replication slow down our production system?
iblync throttles its resource use so it does not compete with production. Throughput depends on your estate, so we measure it on your systems during scoping.
Do you also integrate with government platforms?
Yes, as separate integrations built against each platform's published specification. See our guide to integrating with Saudi digital platforms.
How is it priced?
iblync is quoted per source system, target system and data volume. Integration work is scoped from the interface inventory.
Next
Read next
Next step
Describe the systems you need to connect
Tell us which systems hold the data, which need it, how fresh it must be, and whether it may leave your environment. We will tell you which pattern fits each interface and where iblync does or does not belong.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia