The defining problem in maritime systems is not bandwidth. It is that two copies of the truth exist, they diverge for days at a time, and they must reconcile without producing work for a person.
Decide who owns what
The design decision that prevents most problems.
For each type of record, nominate one side as authoritative:
The vessel owns what happens aboard: maintenance completed, hours run, consumption, defects raised, stock consumed, positions and events.
Shore owns what the organisation decides: the maintenance schedule, crew assignments, voyage instructions, purchase approvals, certificates and their expiry.
Where ownership is clear, conflicts cannot arise, because only one side is generating changes to a given record. The synchronisation becomes a matter of transporting changes rather than resolving disagreements.
Where ownership genuinely must be shared — a defect raised aboard and updated ashore, for instance — the record needs a defined workflow with states, so that each side changes it only at the appropriate stage.
Every conflict resolution rule you have to write is evidence that ownership was not decided clearly enough. Prefer designing conflicts out to resolving them.
Both sides hold a complete copy
A vessel system that queries a shore server to function stops working when the link does, which is exactly when it must not.
The vessel holds everything it needs to operate: the maintenance schedule, the parts catalogue, crew records, procedures, certificates. It records what happens locally, and exchanges with shore when it can.
Shore holds the fleet picture, as current as the last exchange with each vessel, and clearly marked with when that was. A shore user should be able to see that a vessel's data is four days old, rather than assuming it is current.
Exchange changes, not whole datasets
Sending a full copy of the database on every exchange is wasteful and slow.
The workable approach: each side records changes with a sequence and a timestamp, and each exchange sends only what the other side has not yet received. That keeps transfers small enough to complete over a poor link.
Practical requirements:
Resumable transfers. Interrupted transfers continue rather than restarting.
Acknowledgements. Each side knows precisely what the other has received, so nothing is sent twice or assumed delivered when it was not.
Repeat protection. A change received twice must not be applied twice, because retries after interruption will deliver duplicates.
Ordering that does not matter. Changes may arrive out of sequence. The system should tolerate it rather than depending on order.
Attachments need separate handling
Photographs of a defect, scanned certificates, signed documents. These are large relative to the records they belong to, and they are what makes a synchronisation slow.
Handle them separately from the record data: send the record immediately so shore knows the defect exists, and queue the photographs for the next cheap connection.
Resize images aboard before sending. A photograph of a corroded fitting does not need to be eight megapixels to be useful, and reducing it is the difference between arriving today and arriving in port.
Make the state visible
Both sides should be able to see, without asking anybody:
- When the last successful exchange happened
- How many changes are queued and waiting
- Whether anything has failed and needs attention
- The approximate size of what is pending
This matters because the failure mode is silence. A synchronisation that stopped a week ago looks identical to one where nothing has changed, and the difference is only visible if the system says which.
Reconcile deliberately
Even a well-built exchange drifts. A record fails to apply, a transfer is truncated, a change is lost during a restart.
A periodic reconciliation — comparing counts and checksums per record type between vessel and shore, and reporting differences — is what catches this. Weekly is usually enough.
Without it, divergence is discovered during an audit or an inspection, which is the expensive way to find out.
Design for the crew
Aboard, the person entering data has other duties and may not be a computer specialist.
What that means practically: entry that is fast, forms with as few fields as possible, no requirement to understand synchronisation, and clear feedback that something was recorded even though it has not yet reached shore.
Crew work around systems that slow them down, exactly as staff ashore do — see getting staff to use the system. At sea the consequence is worse, because nobody is there to notice.
Certificates and inspections
One area worth building deliberately. Certificate expiry dates matter, and the consequence of missing one is a detained vessel.
The shore system should hold expiry dates and alert well in advance, and the vessel should hold current copies of everything it may be asked to produce — available offline, because an inspection does not wait for a satellite link.
Our team works across maritime and business systems, with a background that includes vessel operations and GMDSS-certified radio work. Start a conversation if your fleet data is being reconciled by hand.
