Extending a Ferry Reservation System: An API Layer Architecture

Why extend the reservation core instead of replacing it?

Extend, do not replace. A mature reservation, ticketing, and check-in platform is the right core for a ferry operator, and rebuilding it is a high-risk programme that rarely addresses the real problem.

Leading operators run on enterprise reservation platforms because a booking core is genuinely hard to build. It holds inventory, capacity, fares, amendments, ticketing, and check-in, all of which must stay consistent under load. That system of record is not where operators lose to competitors.

The gap is around the core. A product shared across many operators cannot prioritise one operator’s routes, contracts, or customers, and should not try to. So the work that differentiates you tends to queue behind a roadmap you do not control. The answer is an owned layer, not a replacement.

This guide is vendor-neutral. It applies to any enterprise reservation platform. Where we reference real delivery, our published CalMac Ferries case study describes application support and integration enhancements for the UK’s largest ferry network.

What is an operator-owned API layer?

An operator-owned API layer is a set of services you build and control that sit between your reservation platform and everything that consumes it. An application programming interface (API) is the contract through which two systems talk. The layer owns those contracts.

Consumers call your layer. The layer calls the reservation core. Nothing else talks to the core directly. That single rule is what makes the pattern work.

The layer does four jobs the core cannot do well for you:

• Translation. It maps the core’s data model into a model that fits your brand, your apps, and your partners.
• Insulation. It shields consumers from the core’s release cycle, so an upgrade to the core does not break your app.
• Augmentation. It adds caching, notifications, analytics capture, and business logic the core does not provide.
• Consolidation. It becomes the single integration surface for ports, hardware, CRM, finance, and reporting.

This is the same pattern systems integrators have long used around large enterprise platforms. The platform stays the system of record. The integrator builds the systems of engagement and insight around it.

What belongs in the core, and what moves to the layer?

The system of record stays; the systems of engagement and insight move out. Keep the mission-critical record of what is booked and what it costs inside the reservation platform. Move everything the passenger touches, and everything you want to analyse, into the layer.

What stays in the reservation core

What moves to the owned layer

The dividing line is ownership of truth. If losing the data would corrupt the record of travel, it stays in the core. If the data is about experience, insight, or a partner relationship, it belongs in the layer.

What does the architecture look like?

The architecture is three tiers: consumers at the edge, your API layer in the middle, and the reservation core plus integrated systems behind it. Every arrow into the core passes through the layer.

A typical shape on Azure looks like this:

• Consumers. Mobile apps (React Native), a booking website, staff and contact-centre tools, and partner portals.
• Edge and gateway. Azure API Management as the front door, handling authentication, rate limiting, versioning, and monitoring.
• API layer services. C#/.NET services that expose your own contracts, hold caches, run business logic, and orchestrate calls to the core.
• Eventing. Azure Service Bus or Event Grid so the layer can react to changes and fan out notifications without blocking.
• Reservation core. The vendor platform, reached only through the layer, using its supported APIs.
• Integrated systems. Ports, automatic number plate recognition (ANPR) and gate hardware, customer relationship management (CRM), finance, and public service obligation (PSO) reporting.

For guidance on the interface style between consumers and the layer, see our comparison of REST, GraphQL, and gRPC. Where different consumers need different shapes of the same data, a backend-for-frontend pattern inside the layer keeps each app clean.

Read paths and write paths are different

Treat reads and writes as separate problems. Reads, such as sailing times and availability, can be cached and served fast. Writes, such as a booking or an amendment, must be handled carefully so the core stays the single source of truth.

Reads are where the layer earns its performance. Writes are where it earns its trust. The next section is about the edge cases in both.

Which edge cases earn credibility?

The edge cases are where an extension layer proves it is safe. Three matter most: cache invalidation when the core amends a sailing, idempotent booking amendments, and degraded mode when the core is under maintenance.

How do you invalidate the cache when the core amends a sailing?

Cache aggressively, but invalidate on events, not just on a timer. If a sailing is retimed or cancelled in the core, a passenger looking at a cached departure time is being misinformed at the worst possible moment.

The reliable pattern has three parts:

• Short time-to-live as a floor. Cache reads with a modest expiry so nothing is ever badly stale, even if an event is missed.
• Event-driven invalidation as the primary mechanism. When the core publishes a sailing change, or your poller detects one, evict the affected keys immediately.
• Versioned cache keys. Key by sailing and a version or last-updated stamp, so a stale entry can never mask a newer one.

If the core cannot push events, the layer polls for changes on a tight schedule and publishes its own internal events. Disruption is exactly where this matters most, which is why it has its own ferry disruption communications guide.

Why must booking amendments be idempotent?

Because mobile networks retry, and a retried amendment must never double-charge or double-book. An operation is idempotent (safe to repeat) when calling it twice has the same effect as calling it once.

A passenger on a car deck with poor signal taps “confirm change”, the request times out, and the app retries. Without idempotency, that is two amendments. With it, the second request returns the result of the first.

The layer enforces this with an idempotency key on every write:

• The client generates a unique key per user action and sends it with the request.
• The layer records the key and the outcome before it calls the core.
• A repeat of the same key returns the stored outcome instead of calling the core again.

This is the same discipline that stops booking systems overselling under load, covered in high-demand bookings without overselling. Where the core owns holds during checkout, follow its model rather than inventing your own, as discussed in reservation and release in checkout flows.

What happens when the core is under maintenance?

The layer runs in degraded mode, not down. When the reservation core is offline for planned maintenance or is under stress, the layer should keep doing everything that does not strictly need the core in real time.

A well-designed degraded mode does the following:

• Serves reads from cache for timetables, availability snapshots, and account history, with a clear “as at” timestamp.
• Queues safe writes where the business allows, holding them in a durable queue and reconciling when the core returns.
• Fails honestly for anything it cannot safely defer, with a clear message rather than a spinner or a silent error.
• Protects the core with circuit breakers, so the layer stops hammering a struggling core and lets it recover.

Degraded mode is a design decision, not an afterthought. Deciding in advance which operations can be queued and which must fail fast is part of the discovery work, and it is where operator-specific knowledge is essential.

How should the integration layer be secured?

Secure the layer as the single front door to the core, and give every consumer least privilege. Because all traffic to the core flows through the layer, the layer is both the chokepoint to protect and the best place to enforce policy.

The essentials:

• One authentication model. Use OAuth 2.0 and Azure Entra ID across consumers, rather than per-integration credentials scattered across systems.
• Least-privilege scopes. A partner portal does not get the same access as a staff tool. Scope tokens to the minimum each consumer needs.
• Rate limiting and quotas at the gateway, so a misbehaving integration cannot overwhelm the core.
• Full audit logging of every call, which supports both incident response and the evidence requirements of standards such as ISO 27001.

We build to ISO 27001 and Cyber Essentials Plus standards, and we design integration surfaces so that security is enforced centrally rather than reimplemented in every consumer. Our API and integration services cover this in delivery.

In what sequence should you build it?

Build in thin, high-value slices, starting with reads. Do not attempt the whole layer at once. Each slice should ship working software and reduce risk before the next begins. This mirrors the phasing in our integration strategy guide.

A sensible order for most operators:

1. Assess the core’s APIs. Establish exactly what the reservation platform exposes, how it authenticates, and where its limits are. This assessment shapes everything else.
2. Stand up the gateway and a read API. Put the gateway in front, and expose a cached sailing-status and availability read. This is low risk and immediately useful.
3. Add the first consumer. Point one app or portal at the layer, proving the translation and caching in production.
4. Introduce eventing and disruption. Add event-driven invalidation and the first proactive notifications, the highest-value capability for most operators.
5. Bring writes into the layer. Add idempotent bookings and amendments, with the degraded-mode behaviour agreed up front.
6. Consolidate integrations. Move ports, hardware, CRM, and reporting onto the owned surface, one system at a time.
7. Open the analytics and partner layer. Capture events for your own analytics, and add ancillary and partner commerce, covered in ferry ancillary revenue.

Each step is independently valuable. If a programme paused after step four, the operator would already have a branded app and proactive disruption communications, with the core untouched.

How does AI-augmented delivery change the build?

AI-augmented delivery compresses the repetitive parts of building the layer, not the judgement. The architecture decisions, the degraded-mode rules, and the core-versus-layer boundary still need experienced people. The scaffolding around them is where AI saves time.

AI-augmented teams move faster on:

• Contract and client generation from the core’s API definitions.
• Mapping and translation code between the core’s model and yours.
• Contract tests that catch a breaking change in the core before it reaches your app.
• Integration adapters for ports, hardware, and reporting systems.

This is why our delivery is publicly evidenced at 40 to 50% faster in the AI Velocity Report, without cutting the quality the core’s stability depends on.

Where to start

1. Assess what your core exposes. You cannot design the layer until you know the reservation platform’s real API surface and limits.
2. Pick one high-value read. Sailing status or availability is usually the right first slice: useful, low risk, and quick to prove.
3. Agree the boundary and the edge cases. Decide together what stays in the core, and how the layer behaves on amendments and during maintenance.

See our ferry and maritime industry hub for the wider picture, our API and integration services for how we deliver, or book a consultation to discuss your core and routes.