Revenge for “a failure seven years ago”: How Agent Memory will reshape the future of booking systems

Seven years ago, I joined a project to build a booking system said to be the third-largest in the world by scale.

The budget was in the tens of billions of yen? (5–6 vendors involved: Marketing, customer profiles, booking system, customer portal, etc.). We planned to customize a major vendor’s package as the base, but the result was—“project canceled.”

The reasons were clear.

• Performance couldn’t keep up: The database couldn’t withstand complex availability calculations across resources.
• Logic collapsed: “Complex bookings,” such as variable service duration per customer, couldn’t be absorbed by the package’s rigid data model—turning the implementation into spaghetti code.

In the end, people talked about rebuilding from scratch, or concluded it wasn’t viable for operations—the现场 (project site) was in shambles.

But now, with rapid advances in generative AI—especially the shift from “RAG to Agent Memory”—we can finally see a path to realizing the ideal we gave up on back then.

In this article, I share a new architecture concept for booking systems in the Agent era (Learn From Pain), based on the “pain” we learned from in the past.

1. Why traditional DB-centric systems “die” under large-scale, complex bookings

Traditional booking systems resemble what, in AI terms, would be called “Naive RAG.” Basically, “every time a user arrives, the system queries the database (DB) and returns the result at that moment.”

💀 Problem ①: The “musical chairs” experience that destroys UX

When traffic spikes, DB lock waits occur. The screen says “available,” but after you enter details and press confirm, you get an error: “it’s taken.” This is the disappointing experience caused by trying to control the time lag between “the moment you searched” and “the moment you confirmed” using only DB transactions.

💀 Problem ②: The limits of dynamic resource calculation

This was the toughest part for me seven years ago. Imagine booking for a “hair removal salon.”

• Customer A (smaller build): Narrower treatment area, so 45 minutes
• Customer B (larger build): Wider treatment area, so 60 minutes

If you try to implement this with SQL or static logic, conditional branches explode. And when you start cross-checking “room availability,” “staff availability,” and “equipment availability,” the load on the DB grows exponentially—and the system goes down.

2. Solution: Make an Agent the “traffic controller (Dispatcher)”

The approach that solves this is “Memory in Agents.”

Instead of sending booking requests directly to the DB, you send them to an Agent that has “context” and “memory.” The Agent holds state and performs high-speed traffic control in memory through interaction with the user.

Architecture comparison

Below is a diagram showing the difference between the traditional model and the Agent-based model.

3. Scenario: What happens inside the Agent’s “brain”

Now, let’s look at a concrete scenario to see how bookings are processed using the Agent’s short-term memory.

Situation: A battle over the last remaining slot on Aug 2, 16:00–

Visualizing the processing flow

Detailed processing inside the Agent

Simultaneous inquiries (14:06:10)

Yamada, Suzuki, and Sato access at the same time. The system does not go to the DB. Their requests enter a queue in the Agent’s memory.

Agent arbitration (14:06:11)

The Agent thinks:

• “There is only 1 slot available.”
• “Mr./Ms. Yamada is a VIP (high LTV).”

Decision: perform a soft lock (temporary hold) in memory for Mr./Ms. Yamada.

3. Responses to users (14:06:12)

• To Yamada: “You can book (we are holding the slot for 5 minutes).”
• To Suzuki and Sato: “Sorry, you are currently on the waitlist.”

4. Handling users who arrive later

Even if Tanaka comes later and searches, the Agent immediately answers “fully booked” based on its own memory. The DB load is zero.

4. Three revolutions brought by the Agent Memory approach

① A reliable UX that avoids “false hope”

It prevents the tragedy of a slot disappearing between “seeing it on screen” and “pressing confirm.” The Agent behaves like a concierge: “I’ve held the seat for you.”

② Solving “complex durations” through dialogue

The Agent can refer to customer profiles (memory). It can dynamically adjust, e.g., “Yamada took longer last time, so let’s allocate 60 minutes instead of the usual 45,” using reasoning without complex system changes. This is the flexibility that package systems couldn’t deliver in the past.

③ Dramatically reduced DB load

Because most read requests can be handled in the Agent’s memory, the backend DB only needs to accept “confirmed bookings (writes).” The performance issue during peak access is fundamentally resolved.

5. From hypothesis to implementation: the next challenge

Of course, the architecture introduced here is still at the “idea” stage. We still need to validate feasibility for real operations—latency, recovery processes when an Agent instance goes down, and more.

However, based on my experience building several Agent systems recently, I am convinced this design is technically feasible.

It’s a natural design that leverages LLMs and Agent characteristics, rather than forcing an RDB to do what it isn’t suited for.

Next Step

To eliminate this “pain,” I plan to build a prototype using Agent Memory and conduct a PoC (technical validation).

• Can it really handle thousands of requests?
• Will the Agent’s memory management hold up without breaking?

I’ll share the results another time, along with technical details.

Conclusion: Ending the nightmare from seven years ago

The “ideal booking system” that couldn’t be achieved even with tens of billions of yen.

Now, with Agentic RAG / Agent Memory, it can be built more simply and more intelligently.

Instead of managing a static database, we manage Agents that hold dynamic state.

This paradigm shift should be the key to building the next generation of booking systems. Please look forward to this experiment and challenge.