Developing a Real-Time Backend for LangGraph AI Agent
Transitioning in-memory booking system to PostgreSQL for production readiness
1From Demo to Product
The LangGraph-based AI agent manages a 15-minute booking process like a customer service representative. Initially, all data was kept in memory, but this approach proved insufficient for real workloads. With Postgres integration, the agent can now operate beyond a single demo process. While keeping the Streamlit UI, the backend was completely redesigned to handle persistent storage and concurrent access.
2Limitations of Memory-Based System
In the current system, bookings were stored in Python lists and LangGraph checkpoints. All data would disappear when the process restarted. More critically, different sessions couldn't see each other's bookings. This led to the agent suggesting conflicting appointments based on stale data. The system essentially behaved no differently than a notebook kernel, making it unreliable for production use.
3PostgreSQL Solution
The open-source relational database PostgreSQL was designed with separate tables for technician information and bookings. The database schema consists of two main tables: 'technicians' and 'bookings'. The PostgresBookingRepository class, with over 100 lines of code, manages these tables. When DATABASE_URL is defined, the system automatically switches to Postgres mode, enabling persistent storage.
4Protocol-Based Architecture
Thanks to the BookingRepository protocol, the system can work in both Postgres and in-memory modes. The list_bookings and create_booking methods work identically in both modes. This flexibility allows using in-memory mode for unit tests and quick demos. The protocol ensures graph nodes can operate without depending on concrete database implementations, following dependency inversion principle.
5Dual Persistence Mechanism
Postgres integration affects two core components: LangGraph checkpoints and the booking engine. Checkpoints save the agent's graph state at each execution step, while the booking engine guarantees appointment consistency. AgentState still serves as the graph's working memory but is now backed by persistent storage. This combination enables both conversational continuity and data integrity.
6Concurrency Control
The old in-memory system used threading.RLock() to control concurrent access to the booking list. With the Postgres migration, this locking mechanism was replaced with database-level transactions. The create_booking method still checks for overlaps, but this operation now occurs at the database level, providing more robust concurrency control and eliminating race conditions.
7Multi-Frontend Support
The new architecture enables support for multiple frontends beyond Streamlit, including platforms like WhatsApp. All frontends share the same Postgres database, ensuring a single source of truth for bookings. This significantly improves data consistency across different access points. The system is now truly product-ready, capable of handling real business scenarios with multiple access channels.
8Significance of Productization
This transformation demonstrates the process of turning a prototype into a real business solution. With Postgres integration, the system has become resilient to restarts, supports multiple concurrent sessions, and enforces real business rules. This step is critical for transitioning AI agents from the demo phase to actual products, showcasing how research concepts can evolve into practical tools that solve genuine business problems.
Original article: Towards Data Science — LangGraph AI Ajanı için Gerçek Zamanlı Backend Geliştirme