Redis Real-Time Decisioning Demo | Onboard Cruise Personalization

Stage 1: The Architecture

Seven thousand six hundred different afternoons, decided on the ship.

Onboard personalization is a capacity problem, not an app problem. A squall closes the outdoor decks, four thousand guests need a new plan, and every recommendation consumes a seat the next guest cannot have. Nobody saw it coming, so the decision runs on the ship. Redis does not decide the recommendation. the line’s models do, against the guest context and live capacity Redis holds.

Data Sources

Guest Profile and CruiseCard

Party links, Compass Club tier, stateroom, preferences and prior sailings — synced from shore before sail-away

App Events (Onboard Mode)

My Calendar adds, show reservations, deck map lookups, chat activity, notification opens

Venue and Reservation System

Live seat and table capacity for Wave Theater, Icecap, Main Theater, specialty dining and activities

Point of Sale / CruiseCard Ledger

Live onboard spend, beverage and dining package status, running account balance

Ship Systems

Weather and sea state, ship time, itinerary and all-aboard timing, venue operating hours, deck closures

Youth Program Registration

Kids Club enrolment by age band and teen space registration, with session capacity

Ingest Layer

Redis Data Integration

CDC from the shipboard reservation and point-of-sale databases — capacity, bookings, ledger. Runs on the ship, no shore round trip

Redis Streams / Kafka

App events, venue capacity changes, deck closure and weather events, notification delivery and response

Redis Context · Shipboard Guest and Capacity Store

Redis RAM

Live guest state, the party graph, today’s bookings, and atomic venue capacity counters that decrement as recommendations are accepted

Redis Flex

Prior sailing history and this cruise’s full event archive at tiered cost, so day 4 knows what days 1 to 3 looked like

Redis Search

Vector match on activity affinity against comparable parties, and venue substitution patterns from prior weather events

Redis Context Retriever

Governed MCP tools over the guest and venue schema, so a concierge assistant queries defined interfaces rather than shipboard systems directly

Redis Agent Memory

Short-term — this guest’s day, across every venue and notification. Long-term — what this household accepted and ignored on previous sailings

Experience Engines

Activity Recommendation Model

Which venue and time to surface for this party. the line’s model

Conflict Detection

Against the guest’s own existing reservations, including dinner and show bookings

Capacity Allocation

Atomic hold and release, so two guests are never promised the last four adjacent seats

Party and Age Rules

Age-appropriateness, youth-program enrolment, and party-size seating together

Every Surface, One View

Cruise Line App

Push notification and My Calendar, on ship time rather than phone time

Digital Deck Map

Wayfinding from where the guest actually is to where they are being sent

Venue Host Devices

The host sees who is arriving and why, so the party is expected

Stateroom TV and Digital Key

Continuity into the stateroom on Horizon-class ships

Learn: Accepted, ignored or over-capacity → written back to the guest view in-session → recommendation model retraining ashore

Decision SLA

<10 ms

Guests re-planned

7,600 in 4.2 s

Decided

Shipboard, not shore

Stage 2: The Squall

14:10, sea day, and the rain just closed four thousand people’s afternoon.

Day 4 of a 7-night sailing on Horizon. A squall closes the pools, the Rapids Waterpark and the sports court within four minutes. Roughly four thousand guests were outdoors, and all reach for the app at once.

The Displacement Event

HZN

Horizon | Day 4, Sea Day

7,600 guests aboard · 14:10 ship time · Eastern Caribbean

DECK CLOSURE EVENT

Eventoutdoor_venue_closure_weather

Closed at 14:10–14:14Sun Deck pools · Rapids Waterpark · Sports Court

Guests displaced~4,000

App sessions opened, 14:10–14:135,180

Indoor seated capacity, next 90 min2,340 across 6 venues

Icecap, 15:00 show400 seats · 34 remaining at 14:12

Notice givenNone — squall not forecast at this position

Ship time vs phone timeShip 14:10 · many phones 13:10

Why One Push Notification Makes It Worse

ONE MESSAGE TO EVERYONE

The fast response is a fleet-standard push: rain on the pool deck, come to the Main Theater. It goes to every guest aboard. Three thousand people start walking toward a venue that seats thirteen hundred, and the ones who arrive last queue in a corridor having been told there was room. Meanwhile Icecap has thirty-four seats nobody is told about, the Marketplace absorbs an unmanaged surge, and a family with an eight o’clock Umi booking gets recommended Umi for lunch. Nothing here is a bad model. It is one decision being made once for seven thousand six hundred different situations.

ONE DECISION PER GUEST, AGAINST LIVE CAPACITY

Each guest’s answer is computed against what is genuinely left at the moment they are asked, with the capacity decremented atomically as answers go out. Guest one gets the ice show. By guest thirty-five the ice show is full and stops being offered. A party of four is only sent somewhere four adjacent seats exist. Anyone with an existing reservation is never recommended a conflict. Seven thousand six hundred guests, seven thousand six hundred answers, four point two seconds, decided on the ship.

Stage 3: Ingest

The decision runs on the ship, because it has to.

Specific to a ship, not a hotel: the durable guest profile syncs from shore before sail-away, and everything that changes during the cruise — bookings, capacity, spend, closures — is captured shipboard by change data capture and streamed locally.

Redis Data IntegrationRedis Streams / Kafka

Shipboard Sources → Guest and Capacity View

GST

Guest Profile and CruiseCard — synced pre-sail

Party links, Compass Club tier, stateroom, preferences, prior sailings. Loaded before sail-away, not fetched at sea

→

VEN

Venue and Reservation System — live capacity

Seats and tables for Wave Theater, Icecap, Main Theater, specialty dining — shipboard CDC via Redis Data Integration

→

APP

App Events — Onboard Mode

Calendar adds, show reservations, deck map lookups, notification opens. Streamed as they happen

→

POS

Point of Sale / CruiseCard Ledger

Live spend and package status — shipboard CDC. Used for eligibility, never to gate an experience

→

SHP

Ship Systems — weather and time

Sea state, deck closures, ship time, all-aboard timing, venue hours

→

YTH

Youth Program Registration

Kids Club by age band and teen space enrolment, with live session capacity

→

Redis Data Integration Pipeline Status

CDC modeReal-time — shipboard reservation and POS databases

Reservation and capacity CDC lagunder 1 sec

Point of Sale ledger CDC lagunder 1 sec

App and venue event ingestRedis Streams — under 200 ms

Guest profile syncPre-sail from shore — full manifest aboard before departure

Guest coverageFull manifest — all 7,600, every venue

Shore round trips in the decision path0

Shore sync of outcomesDeferred — sent when satellite bandwidth allows

The satellite link is the constraint that shapes this whole design. Guest profiles are heavy and slow-moving, so they come aboard before the ship sails. Capacity is light and fast-moving, so it lives shipboard and is read in microseconds. Shore receives the outcomes when there is bandwidth, and the guest standing in the rain on deck fifteen never waits on any of it.

Stage 4: Guest Context

The Alvarez party, on deck 15, in the rain, with an eight o’clock booking.

Redis RAM holds where they are and what is still open across the ship. Redis Flex carries four prior sailings and this one. Redis Search matches activity affinity against comparable parties. Agent Memory holds the thread of their day.

Redis RAMRedis FlexRedis SearchRedis Agent Memory

Guest 360 (Party)

PartyJennifer and Marco Alvarez · Sofia 14 · Mateo 9

StateroomsConnecting balcony 10248 / 10250, deck 10

Compass ClubSapphire · 68 points · this sailing clears Onyx

Current locationDeck 15, Sun Deck — displaced at 14:11

Booked tonightUmi, 20:00, party of 4

Youth programsMateo — Kids Club, ages 9–11 · Sofia — teen space

CruiseCardBeverage package active · balance $284

Day 1–3 pattern2 family shows attended, 1 trivia, no adults-only venues

Live Options at 14:12

Icecap, 15:0034 of 400 seats · 4 adjacent available

Walk time from deck 156 minutes, 2 decks down

Ends 15:45 — clear of 20:00 UmiYes, no conflict

Age-appropriate for 9 and 14Yes — family ice production

Wave Theater, 14:4512 seats, all scattered singles

Main Theater, 14:451,300 seats · absorbing displaced surge

Umi lunch seatingOpen — but they hold a 20:00 Umi booking

Party-affinity match (Redis Search)0.86 — family productions

The conflict check is the one that would embarrass you. Umi has lunch availability and the attach model likes specialty dining for this household, so on a naive ranking it wins. It is the wrong answer because they are already going to Umi at eight tonight — a fact that lives in the reservation system, not in the recommendation model. One view means the ranker sees their own booking before it speaks.

Agent Memory

Short-term (today)09:20 Marketplace · 11:00 Kids Club drop-off · 12:40 Sun Deck · 14:11 displaced. Thread continuous

Long-term (4 prior sailings)Attends family productions, skips adults-only and casino. Accepted 7 of 9 app recommendations

Learned preferenceResponds to bookable seated activities, ignores open-ended “come join us” nudges

Memory persistenceDay thread → Redis RAM (TTL: sailing) · Outcomes → Redis Flex, synced ashore at berth

Stage 5: Feature Serving

78 guest and capacity features, served 7,600 times in 4.2 seconds.

Every one of these reads has to happen per guest, and the capacity features change while the fan-out is still running. That is the part a nightly segment cannot do.

Redis RAMRedis SearchRedis Flex

venue_seats_remaining_live

Seats actually left at the candidate venue at this instant, decremented atomically as offers are accepted

34 of 400 · Icecap 15:000.2 ms

party_adjacent_seat_block

Whether the party’s size can be seated together, not merely admitted

4 adjacent · confirmed0.3 ms

own_booking_conflict_flag

Whether a candidate collides with a reservation this guest already holds

TRUE for Umi — 20:00 booking0.2 ms

walk_time_from_current_deck

Minutes from the guest’s present location to the venue, using the deck map graph

6 min · deck 15 to deck 130.4 ms

age_band_appropriateness

Fit against the party’s actual ages and youth-program enrolment

Cleared for 9 and 140.2 ms

party_activity_affinity

Activity affinity from prior sailings and comparable parties (Redis Search)

0.86 — family productions0.5 ms

TOTAL FEATURES

P99 LATENCY

4.9 ms

GUESTS RE-PLANNED

7,600 in 4.2 s

DECIDED

Shipboard

Stage 6: Activity Decision

Their model ranks it. Redis makes sure the seat is still there.

The boundary again: Redis does not decide the recommendation. the line’s experience models rank these options. Redis makes that ranking happen against live capacity and this party’s own bookings, so the winner is somewhere they can actually be seated.

Activity Recommendation ModelConflict DetectionCapacity Allocation

78 features evaluated

Capacity decremented atomically

Own-booking conflict checked

Ranked in 6.7ms

#1 Ranked

ICECAP · 15:00

Ice production, 4 adjacent seats, 6 minutes away

Ends 15:45, clear of their 20:00 Umi · age-appropriate for 9 and 14 · seats held 90 seconds

Their model ranked this first. Redis supplied the three things that make it a real answer rather than a guess: four seats together still exist, the party can walk it in six minutes from where they are standing, and it does not collide with dinner.

Decision score89%

#2 Ranked

WAVE THEATER · 14:45

Skydome show, 12 seats remaining

Ranked second — all 12 are scattered singles, so a party of four cannot sit together

Capacity is not a single number. Twelve free seats reads as availability and is unusable for this party. Admitted-but-separated is a worse guest experience than being sent somewhere else.

Decision score8%

#3 Evaluated

UMI LUNCH SEATING

Specialty dining, open seating this afternoon

Suppressed — this party already holds a 20:00 Umi reservation tonight

The attach model likes this: the household books specialty dining on most sailings and there is availability. It is still wrong, because recommending the same specialty restaurant twice in one day reads as a system that does not know them. The reservation is in the reservation system; the recommendation came from a model. One view is what puts them in the same call.

Decision score1%

Stage 7: Business Impact

The afternoon a squall did not ruin.

Onboard revenue and guest satisfaction move together here. The figures below are per ship per year, every input labelled, and two of the three are ours. Redis does not decide the recommendation. Their models do.

The Model

Guests per Horizon-class sailing7,600 — theirs, public capacity

Sailings per ship per year52

Incremental onboard spend per guest per sailingthe one input we vary

Conservative ($4 per guest)$1.6M per ship / yr

Midpoint ($8 per guest)$3.2M per ship / yr

Aggressive ($16 per guest)$6.3M per ship / yr

BasisGross of any Redis licence · per ship, not per fleet

Unpriced and named, not countedAvoided venue overcrowding, and the guest-satisfaction effect of not being sent somewhere full

Conservative and aggressive vary exactly one input. Guest count and sailing frequency are the line’s own published figures; the incremental spend per guest is a Redis assumption and should be replaced with their onboard revenue data in the first session. Note the model is deliberately per ship — the Horizon-class pattern extends across the class, but multiplying it here would be us arguing with ourselves.

What the Squall Actually Costs Today

1 push

one message to 7,600 guests

→

7,600

decisions in 4.2 s

VENUE OVERCROWDING

3,000

sent to 1,300 seats

SEATS NOBODY WAS TOLD ABOUT

at Icecap

The cost of the naive push is not only the revenue nobody captured. It is four thousand guests learning, on day 4 of 7, that the app sends them to full rooms.

Stage 8: Outcome

Same squall, same ship, two afternoons.

Nothing changes about the weather, the venues, or their recommendation models. The only variable is whether each decision could see what was actually left.

One Push to Everyone

PUSH NOTIFICATION — ALL GUESTS

RAIN ON THE POOL DECK — HEAD TO THE MAIN THEATER

One decision, 7,600 recipients, no capacity in view

RecipientsAll 7,600 guests

Venue namedMain Theater, 1,300 seats

Guests who walked there~3,000

Turned away at the door~1,700

Icecap34 seats unsold, unmentioned

The Alvarez partyRecommended Umi — they dine there at 20:00

OUTCOME

OVERCROWDED

One decision made once for 7,600 situations · a corridor queue · and a family told to eat twice at the same restaurant

1,700

turned away

seats unsold

decision

One Decision Per Guest

4 SEATS HELD — ICECAP 15:00

8.3ms

The Alvarez Party — Stateroom 10248

Icecap · 15:00 · 4 seats together

Six minutes from where you are, two decks down. Ends at 15:45, well before your eight o’clock at Umi. Held for 90 seconds while you decide.

Recipients7,600 individual decisions

Venue namedDifferent for each party

CapacityDecremented as offers accepted

Turned away at the door0

IcecapFilled, 34 seats sold

The Alvarez partyIce show — no Umi conflict

OUTCOME

SEATED

Every guest sent somewhere with room for their party · no corridor queues · no venue oversold · decided on the ship in 4.2 seconds

turned away

7,600

decisions

4.2 s

to decide all

Stage 9: Architecture Recap

Every guest. Every venue. Every afternoon the weather changes.

A squall is the clearest version, not the only one: a port delay, a sold-out excursion, an all-aboard countdown. Many guests, finite shared capacity, a decision made on the ship. Their models stay theirs; Redis contributes what is genuinely left.

Data Sources

Guest Profile and CruiseCard

Party links, Compass Club tier, stateroom, preferences and prior sailings — synced from shore before sail-away

App Events (Onboard Mode)

My Calendar adds, show reservations, deck map lookups, chat activity, notification opens

Venue and Reservation System

Live seat and table capacity for Wave Theater, Icecap, Main Theater, specialty dining and activities

Point of Sale / CruiseCard Ledger

Live onboard spend, beverage and dining package status, running account balance

Ship Systems

Weather and sea state, ship time, itinerary and all-aboard timing, venue operating hours, deck closures

Youth Program Registration

Kids Club enrolment by age band and teen space registration, with session capacity

Ingest Layer

Redis Data Integration

CDC from the shipboard reservation and point-of-sale databases — capacity, bookings, ledger. Runs on the ship, no shore round trip

Redis Streams / Kafka

App events, venue capacity changes, deck closure and weather events, notification delivery and response

Redis Context · Shipboard Guest and Capacity Store

Redis RAM

Live guest state, the party graph, today’s bookings, and atomic venue capacity counters that decrement as recommendations are accepted

Redis Flex

Prior sailing history and this cruise’s full event archive at tiered cost, so day 4 knows what days 1 to 3 looked like

Redis Search

Vector match on activity affinity against comparable parties, and venue substitution patterns from prior weather events

Redis Context Retriever

Governed MCP tools over the guest and venue schema, so a concierge assistant queries defined interfaces rather than shipboard systems directly

Redis Agent Memory

Short-term — this guest’s day, across every venue and notification. Long-term — what this household accepted and ignored on previous sailings

Experience Engines

Activity Recommendation Model

Which venue and time to surface for this party. the line’s model

Conflict Detection

Against the guest’s own existing reservations, including dinner and show bookings

Capacity Allocation

Atomic hold and release, so two guests are never promised the last four adjacent seats

Party and Age Rules

Age-appropriateness, youth-program enrolment, and party-size seating together

Every Surface, One View

Cruise Line App

Push notification and My Calendar, on ship time rather than phone time

Digital Deck Map

Wayfinding from where the guest actually is to where they are being sent

Venue Host Devices

The host sees who is arriving and why, so the party is expected

Stateroom TV and Digital Key

Continuity into the stateroom on Horizon-class ships

Learn: Accepted, ignored or over-capacity → written back to the guest view in-session → recommendation model retraining ashore

Decision SLA

<10 ms

Guests re-planned

7,600 in 4.2 s

Decided

Shipboard, not shore