Real-Time Decisioning Demo | Cruise Booking Personalization
Pipeline<10ms
Illustrative
1 / 9
1
Architecture
2
The Seventh Session
3
Ingest
4
Shopper Context
5
Features
6
Offer Decision
7
Impact
8
Outcome
9
Recap
Stage 1: The Architecture
Deciding the offer while the page is still rendering.
A cruise shopper makes six decisions — ship, sailing, itinerary, category, cabin, add-ons — over weeks and devices. By the deck plan, the connecting cabins that fit a family of four have moved. Redis does not price the cruise and does not decide the promotion. Revenue management does. Redis assembles eighteen days of shopping context and the live cabin picture inside the page render.
Data Sources

Web and App Clickstream

Sessions, ships viewed, date and itinerary filters, cabin categories browsed, abandonment points — 18 days of exploration across phone and desktop

Compass Club

Tier, cruise points, prior sailings, member rate eligibility. Sapphire at 55 points, Onyx at 80

Reservation System

Live stateroom inventory by ship, sailing and specific cabin number, including which cabins connect

Revenue Management

Fare class, dynamic pricing, promotion eligibility and stacking rules. the line’s models, unchanged

Trip Planner

Beverage, dining, Wi-Fi, spa, shore excursion and photo package inventory and capacity

Guest Profile / CRM

Party composition, stateroom history, dining and excursion preferences from prior sailings

Ingest Layer

Redis Data Integration

CDC from the reservation system, Compass Club and CRM — cabin inventory, tier and points, prior sailing history. Sub-second lag, pipelines configured rather than coded

Redis Streams / Kafka

Clickstream events, cabin holds and releases, price and promotion changes, Trip Planner capacity movement

Redis Context · Shopper and Inventory View

Redis RAM

Live shopper session state, active cabin holds, current inventory counts by cabin, applied promotions

Redis Flex

18 days of this shopper’s exploration plus prior sailing history and package purchase behaviour — years at tiered cost

Redis Search

Vector match on itinerary and ship affinity against comparable parties, plus similar-party package attach patterns

Redis Context Retriever

Governed MCP tools over the booking schema so a shopping assistant queries defined interfaces rather than the reservation system directly

Redis Agent Memory

Short-term — this session’s thread. Long-term — what this household has booked, declined and added across previous cruises

Offer and Pricing Engines

Sailing and Cabin Ranker

Which ship, sailing and specific cabins to surface for this party

Revenue Management / Pricing

Fare, member rate and dynamic price. the line’s models

Promotion Eligibility

Stacking rules, Compass Club benefits, current campaign eligibility

Package Attach Model

Which Trip Planner add-ons to surface, and when

Every Surface, One View

the booking site

Sailing results, deck plan and cabin selection, rendered with cabins that are actually available

Cruise Line App

Pre-Cruise Planning mode — the same view the website used, so the shopper does not start over

Call Centre Agent Desktop

The agent sees the same 18 days of context the shopper does, so the conversation starts mid-stream

Trip Planner

Add-on offers aligned to the party and sailing just chosen

Learn: Booked, abandoned or added → written back to the shopper view in-session → offer model retraining
Decision SLA
<10 ms
Sessions unified
7 over 18 days
Cabin inventory freshness
Sub-second
Stage 2: The Seventh Session
Seventh session, eighteen days, and she has abandoned at the deck plan twice.
Jennifer Alvarez is shopping a 7-night sailing for four, with kids of fourteen and nine. Compass Club Sapphire, 68 points, twelve short of Onyx. Eighteen days, phone and laptop. Twice she reached the deck plan hunting two connecting balcony cabins and closed the tab.
The Shopper
JA
Jennifer Alvarez | Compass Club Sapphire
68 cruise points · 12 from Onyx · 4 prior sailings · party of 4
SESSION 7 OF 7
Sessions7 over 18 days — 4 mobile, 3 desktop
Ships viewedHorizon (5x), Aurora (3x), Cascade (1x)
Filter applied every sessionBalcony, 4 guests, connecting
Abandoned atDeck plan / cabin selection — twice
Sailing windowMarch, 7 nights, Eastern Caribbean
Party2 adults, children aged 14 and 9
Compass Club member rateEligible
Connecting balcony pairs left, Mar 14 Horizon3
Why She Left Twice
WHAT SHE SEES TODAY
The deck plan renders from a cached inventory snapshot, so some of the cabins it shows as available are already gone, and it does not mark which pairs actually connect. She picks two that look adjacent, gets an error at the next step, goes back, and the plan has changed underneath her. Her Sapphire rate appears three steps later, after she has already anchored on a higher price. Nothing in the page knows she has done this twice before, or that she has filtered to connecting balconies in all seven sessions. So the page treats her like a first-time visitor, and she leaves for the third time.
WHAT ONE VIEW MAKES POSSIBLE
The page opens on the three connecting balcony pairs that are genuinely available on the March 14 Horizon sailing, with 10248 and 10250 surfaced first because they are the only pair on a deck with both a teen space and Kids Club within two decks. Her Sapphire member rate is already applied in the first price she sees, and the page notes she is twelve points from Onyx, which this sailing would clear. The pair is held for the duration of her session. Eighteen days of context arriving in 7.8 milliseconds.
Stage 3: Ingest
Eighteen days of context, and inventory that is true right now.
Two freshness problems meet in one page. Her history must persist across weeks and devices; the cabin inventory must be right this second. Redis Data Integration keeps reservations and loyalty current by change data capture; Redis Streams carries clickstream and cabin holds.
Redis Data IntegrationRedis Streams / Kafka
Source Systems → Shopper and Inventory View
CLK
Web and App Clickstream — 18 days / 7 sessions
Ships viewed, filters applied, and both abandonment points at the deck plan
→
RES
Reservation System — live cabin inventory
Specific cabin numbers, availability, and the connecting-cabin relationships — CDC via Redis Data Integration
→
CC
Compass Club — tier and points
Sapphire, 68 points, 4 prior sailings, member rate eligibility — CDC
→
RM
Revenue Management — price and promotion
Fare class, dynamic price, promotion stacking. the line’s models; only the resulting price lands in Redis
→
TP
Trip Planner — add-on capacity
Beverage, dining, excursion and Wi-Fi package inventory for the sailings in view
→
CRM
Guest Profile — household history
Party composition, stateroom history, dining and excursion preferences from 4 prior sailings
→
Redis Data Integration Pipeline Status
CDC modeReal-time — reservation, Compass Club, CRM
Reservation system CDC lagunder 1 sec
Compass Club and CRM CDC lagunder 1 sec
Clickstream and cabin-hold ingestRedis Streams — under 200 ms
Revenue management price feedRedis Streams — resulting price only
Trip Planner capacity movementRedis Streams — under 1 sec
Shopper coverageFull base — every session, every device
Custom sync code0 lines (configured, not written)
The cabin inventory is the part that matters most and is hardest to fake. A deck plan built from a fifteen-minute-old snapshot will show cabins that are sold, and every one of those is a shopper hitting an error at the moment they had finally decided. Change data capture from the reservation system means the plan renders against what is actually available, including which pairs connect — which is the single fact her last two sessions could not tell her.
Stage 4: Shopper Context
Eighteen days, seven sessions, two devices, one view.
Redis RAM holds the live session and current cabin counts. Redis Flex carries her exploration history and four prior sailings at tiered cost. Redis Search matches itinerary and ship affinity against comparable parties. Agent Memory keeps the thread across all seven sessions.
Redis RAMRedis FlexRedis SearchRedis Agent Memory
Shopper 360
Compass ClubSapphire · 68 points · 12 from Onyx
Prior sailings4 — Aurora class 2x, Cascade class 1x, Meridian class 1x
Prior cabins bookedBalcony every time, never inside or oceanview
Prior add-onsBeverage package 4 of 4 · specialty dining 3 of 4 · excursions 2 of 4
Party2 adults + children 14 and 9
Sessions this shop7 over 18 days, 4 mobile / 3 desktop
Consistent filterBalcony, 4 guests, connecting — all 7 sessions
Abandonment pointsDeck plan, sessions 4 and 6
Live Inventory and Eligibility
Connecting balcony pairs, Mar 14 Horizon3 remaining
Pair 10248 / 10250Available · deck 10
Kids Club proximity (age 9)Deck 8 — 2 decks
Teen space proximity (age 14)Deck 15 — reachable, Family Deck deck 7
Sapphire member rateApplied to first price shown
Onyx proximityThis sailing clears 80 points
Party-affinity match (Redis Search)0.90 — balcony + beverage + specialty
Session hold on surfaced pairHeld for session duration
The three facts that decide this page are in three different systems today: what she has been filtering for across eighteen days, which cabins are genuinely free this second, and that she is twelve points from Onyx. None of those is hard to retrieve on its own. Assembling all three inside a page render is the part that does not happen today.
Agent Memory
Short-term (this shop)7 sessions linked across 2 devices · both deck-plan abandonments recorded · filter intent stable
Long-term (4 prior sailings)Balcony every sailing · beverage package every sailing · specialty dining 3 of 4
Learned preferenceNever books inside or oceanview. Surfacing them costs a slot and teaches her the results are not tuned
Memory persistenceSession thread → Redis RAM (TTL: 30 days) · Booking outcomes → Redis Flex (permanent)
Stage 5: Feature Serving
124 shopper and inventory features in 4.6ms.
The price comes from revenue management. The ranking comes from their offer model. Everything that makes both of them correct for this shopper, in this session, against this second’s inventory, is served from Redis in the same call.
Redis SearchRedis FlexRedis RAM
connecting_pairs_available
Connecting cabin pairs in the filtered category actually free right now
3 pairs · Mar 14 Horizon0.3 ms
filter_intent_stability
How consistently this shopper has filtered the same way across sessions
7 of 7 sessions — balcony, connecting0.2 ms
abandonment_step_recurrence
Which funnel step this shopper has abandoned at, and how often
Deck plan · 2 occurrences0.2 ms
tier_threshold_proximity
Cruise points to the next Compass Club tier, and whether this sailing clears it
12 points to Onyx · clears0.3 ms
party_cabin_geometry_fit
Whether available cabins fit the party’s size and age composition, including kids-club proximity
Pair 10248/10250 · both clubs within 2 decks0.5 ms
household_attach_affinity
Add-on attach likelihood from this household’s prior sailings (Redis Search)
0.90 — beverage + specialty dining0.4 ms
TOTAL FEATURES
124
P99 LATENCY
4.6 ms
INVENTORY FRESHNESS
Sub-second
SESSIONS UNIFIED
7
Stage 6: Offer Decision
Their engine chooses. Redis makes sure it chooses against what is actually available.
The boundary: Redis does not price this sailing and does not rank these options. the line’s revenue management and offer models do both. What changes is that they can read eighteen days of intent and this second’s cabin inventory in one call.
Sailing and Cabin RankerRevenue ManagementPromotion Eligibility
124 features evaluated
Inventory confirmed live
Sapphire rate applied
Ranked by their engine in 6.4ms
#1 Ranked
HORIZON · MAR 14 · 10248 + 10250
Connecting balcony pair, deck 10, Sapphire rate applied
Both kids’ clubs within 2 decks · pair held for the session · this sailing clears Onyx
Their ranker put this first. Redis contributed three things it could not otherwise see in the render: that she has filtered to connecting balconies in all seven sessions, that this specific pair is free this second, and that the sailing takes her past 80 points.
Decision score91%
#2 Ranked
AURORA · MAR 14 · LOWER FARE
Cheaper sailing, same week, same itinerary length
Ranked second despite the lower price — no connecting balcony pairs left in her band
A price-led ranking would surface this first. It is the wrong answer for this party, because the thing she has been unable to find for eighteen days is not a fare, it is two cabins that connect.
Decision score7%
#3 Evaluated
INSIDE STATEROOM PROMO
Current campaign: inside stateroom, 4 guests, reduced deposit
Suppressed — never booked an inside or oceanview cabin in 4 sailings, and filtered to balcony 7 sessions running
This is the live campaign, and on a generic page it wins a slot because the discount is the largest. Showing it to her spends a slot and teaches her the results are not tuned to what she has been asking for all month.
Decision score2%
Stage 7: Business Impact
Recovering the step where the family shopper gives up.
The model below is one funnel step, not whole-funnel conversion, and every input is labelled; two of the three are Redis assumptions. Redis does not price the cruise and does not decide the promotion. Their engines decide; Redis supplies the context.
The Model
Sessions abandoning at stateroom selection, per year1,200,000 — Redis assumption
Recovery rate from a correct, live deck planthe one input we vary
Contribution per recovered booking$400 — Redis assumption
Conservative (1% recovery)$4.8M / yr
Midpoint (2% recovery)$9.6M / yr
Aggressive (4% recovery)$19.2M / yr
BasisGross of any Redis licence
Unpriced upsideAdd-on attach lift from surfacing packages this household already buys
Conservative and aggressive vary exactly one input — the recovery rate. The abandonment volume and the contribution figure are both Redis assumptions and should be replaced with the line’s own funnel numbers in the first working session. We would rather show the arithmetic with visible seams than present one number and defend it.
Why the Step Matters More Than It Looks
Cached
deck plan built from a cached snapshot
→
Live
deck plan true to this second
WHERE SHE ABANDONED
Deck plan, twice
sessions 4 and 6
WHAT SHE WAS LOOKING FOR
2 cabins that connect
balcony, 4 guests, all 7 sessions
Stateroom selection is the last step before payment and the first step where the shopper has to reconcile their family against real cabin geometry. An error here does not lose a click, it loses a booking that was already decided.
Stage 8: Outcome
Same shopper, same sailing, two page renders.
Nothing changes about her, the ship, or their pricing models. The only variable is what the page could see when it rendered.
Cached Snapshot
BOOKING SITE — HORIZON, MAR 14
DECK PLAN — CABIN UNAVAILABLE
Rendered from a cached inventory snapshot
Cabins shownSome already sold
Connecting markedNo
Sapphire rateApplied at step 4
Onyx proximityNot surfaced
Session contextTreated as first visit
ResultAbandoned, third time
OUTCOME
ABANDONED
A deck plan she cannot trust, a rate that appears after she has anchored on a higher price, and no memory of six previous attempts
3rd
abandon
0
booked
7
sessions wasted
One Shopper View
BOOKING SITE — HORIZON, MAR 14
DECK PLAN — 3 CONNECTING PAIRS
7.8ms
Jennifer Alvarez — Compass Club Sapphire
Horizon · Mar 14 · Balcony 10248 + 10250
Two connecting balconies on deck 10, held while you decide. Kids Club two decks down, Family Deck for Sofia. Your Sapphire rate is in the price shown. This sailing takes you past 80 points — Onyx.
Cabins shownAvailable this second
Connecting markedYes, pairs surfaced first
Sapphire rateIn the first price shown
Onyx proximitySurfaced — sailing clears it
Session context7 sessions, 2 devices
ResultBooked, with beverage + specialty added
OUTCOME
BOOKED
The cabins she had been unable to find for eighteen days, surfaced first and held while she decided
Booked
this session
2
add-ons
1
render
Stage 9: Architecture Recap
Every shopper. Every session. One view.
Her journey is measured in weeks and the inventory in seconds, and the page has to be right about both at once. That is a data-layer problem, not a merchandising one. Pricing, promotions and ranking stay theirs; the page renders against what is true.
Data Sources

Web and App Clickstream

Sessions, ships viewed, date and itinerary filters, cabin categories browsed, abandonment points — 18 days of exploration across phone and desktop

Compass Club

Tier, cruise points, prior sailings, member rate eligibility. Sapphire at 55 points, Onyx at 80

Reservation System

Live stateroom inventory by ship, sailing and specific cabin number, including which cabins connect

Revenue Management

Fare class, dynamic pricing, promotion eligibility and stacking rules. the line’s models, unchanged

Trip Planner

Beverage, dining, Wi-Fi, spa, shore excursion and photo package inventory and capacity

Guest Profile / CRM

Party composition, stateroom history, dining and excursion preferences from prior sailings

Ingest Layer

Redis Data Integration

CDC from the reservation system, Compass Club and CRM — cabin inventory, tier and points, prior sailing history. Sub-second lag, pipelines configured rather than coded

Redis Streams / Kafka

Clickstream events, cabin holds and releases, price and promotion changes, Trip Planner capacity movement

Redis Context · Shopper and Inventory View

Redis RAM

Live shopper session state, active cabin holds, current inventory counts by cabin, applied promotions

Redis Flex

18 days of this shopper’s exploration plus prior sailing history and package purchase behaviour — years at tiered cost

Redis Search

Vector match on itinerary and ship affinity against comparable parties, plus similar-party package attach patterns

Redis Context Retriever

Governed MCP tools over the booking schema so a shopping assistant queries defined interfaces rather than the reservation system directly

Redis Agent Memory

Short-term — this session’s thread. Long-term — what this household has booked, declined and added across previous cruises

Offer and Pricing Engines

Sailing and Cabin Ranker

Which ship, sailing and specific cabins to surface for this party

Revenue Management / Pricing

Fare, member rate and dynamic price. the line’s models

Promotion Eligibility

Stacking rules, Compass Club benefits, current campaign eligibility

Package Attach Model

Which Trip Planner add-ons to surface, and when

Every Surface, One View

the booking site

Sailing results, deck plan and cabin selection, rendered with cabins that are actually available

Cruise Line App

Pre-Cruise Planning mode — the same view the website used, so the shopper does not start over

Call Centre Agent Desktop

The agent sees the same 18 days of context the shopper does, so the conversation starts mid-stream

Trip Planner

Add-on offers aligned to the party and sailing just chosen

Learn: Booked, abandoned or added → written back to the shopper view in-session → offer model retraining
Decision SLA
<10 ms
Sessions unified
7 over 18 days
Cabin inventory freshness
Sub-second
Press ← → or click to navigate