Designing Leo: High-level Overview of a Social Video Commerce Platform
The creation of Leo Network, a social video commerce platform, was a multifaceted journey that required combining robust technical engineering with an intuitive user experience. Leo aimed to bridge the gaps in peer-to-peer commerce left by platforms like Instagram, focusing on live video interactions, secure transactions, and buyer-seller trust. This blog dives deep into the architectural, engineering, and UX design principles that powered Leo’s success, offering an in-depth exploration for product managers and engineers alike.
System Architecture: Modular, Real-Time, and Scalable
Leo Network’s architecture was designed to handle dynamic use cases, including live video sales, catalog management, secure transactions, and analytics processing. The backend was built on Node.js, leveraging its non-blocking I/O capabilities for high concurrency, while the frontend used Flutter, providing seamless cross-platform performance. The database layer relied on SQL, chosen for its structured query capabilities and relationship handling between buyers, sellers, and products.
1. Microservices Architecture
Leo adopted a microservices-based approach, decoupling functionality into independently deployable services. Each service was containerized using Docker and orchestrated with Kubernetes, enabling scalability and fault isolation. Here’s a detailed breakdown of the core services:
1.1. Catalog Service
- Purpose: Centralized management of product metadata, inventory, and SKUs.
- Design:
- Products were stored with attributes such as size, color, material, price, and seller ID.
- Tagging allowed efficient categorization and retrieval via Elasticsearch, which provided fast full-text search and filtering capabilities.
- Videos and images were stored in AWS S3 with media links stored in the database for efficient retrieval.
- Performance Optimization:
- Frequently accessed data, such as bestseller products, was cached using Redis, reducing query latency.
- Write-heavy operations, like bulk CSV imports, were offloaded to message queues (RabbitMQ) for asynchronous processing.
1.2. Live Sales Service
- Purpose: Real-time streaming and interaction engine for live sales.
- Implementation:
- Video streaming was powered by WebRTC, which enabled low-latency peer-to-peer communication.
- Redis Pub/Sub facilitated real-time updates, such as product availability, price changes, and cart status.
- Dynamic overlays synchronized product details with live streams, ensuring buyers could seamlessly purchase highlighted items.
- Concurrency Management:
- Leveraged STUN/TURN servers to handle NAT traversal for video connections.
- Rate-limiting mechanisms ensured consistent performance during high-traffic live events.
1.3. Order Management Service
- Purpose: Handle the end-to-end lifecycle of a purchase.
- Design:
- Used the SAGA pattern for distributed transaction management, ensuring consistency between inventory updates, payment authorization, and order confirmation.
- Integrated with Razorpay for payments and implemented COD workflows with delayed fund settlement for buyer satisfaction.
1.4. Engagement Analytics Service
- Purpose: Provide actionable insights to sellers and platform administrators.
- Data Pipeline:
- Event data (e.g., views, clicks, sales) was ingested via Apache Kafka.
- Streamed data was processed in real time using Apache Flink and stored in Snowflake for analytical queries.
- Insights Delivered:
- Live sale metrics: total minutes watched, peak concurrent viewers, revenue per sale.
- Engagement trends: identifying optimal times for live sales based on historical data.
2. Database Design
The SQL database architecture ensured structured and normalized data handling for platform operations.
Schema Details:
- Products Table:
- Stored metadata like category, size, material, price, and inventory count.
- Indexed by tags (seller, category) for efficient querying.
- Users Table:
- Maintained buyer and seller profiles with encrypted credentials.
- Included a loyalty program balance tied to Leo Coins.
- Orders Table:
- Tracked transactions, shipping statuses, and payment details.
Data Integrity:
- ACID Transactions were enforced for critical operations such as inventory deduction and order placement.
- Historical data, such as old sales, was archived into cold storage to reduce the load on the primary database.
3. Real-Time Synchronization
Real-time updates were central to Leo’s live sales functionality. Buyers needed immediate feedback on inventory availability, price changes, and cart status during live streams.
Technologies:
- WebSockets provided persistent, bidirectional communication for real-time interactions.
- Eventual Consistency: Data changes were broadcast immediately to the UI while being asynchronously persisted in the database.
- Failover Mechanisms: Redis replicas ensured continued operation during backend disruptions.
Challenges and Solutions:
- Challenge: Managing high concurrency during peak live events.
- Solution: Horizontal scaling via Kubernetes ensured additional instances could be spun up dynamically.
- Challenge: Keeping buyer interfaces synchronized with seller actions in live sales.
- Solution: A lightweight state management system tracked live-sale state changes and broadcast them incrementally.
UX Design: Crafting Seamless User Journeys
Leo’s UX philosophy was rooted in minimizing cognitive load while emphasizing video-first commerce.
1. Buyer Journey
- Video-Powered Product Pages:
- Live sale clips could be attached to product pages, resulting in a 3-3.5x higher conversion rate for video-supported products.
- Streamlined Navigation:
- Buyers could toggle seamlessly between search results, live streams, and cart pages.
- Interactive filters allowed narrowing results by size, price, or material.
- Micro-Animations:
- Added feedback for key actions like cart additions or live stream joining, improving perceived performance.
2. Seller Tools
- Dynamic Dashboards:
- Provided engagement metrics such as total minutes watched, peak viewers, and revenue trends.
- Included actionable insights, e.g., recommending optimal live sale timings based on historical data.
- Live Sale Scheduler:
- Allowed multi-platform streaming with integrated product displays.
- Sellers could preload product queues and dynamically feature them during streams.
3. Gamification and Loyalty
- Leo Coins:
- Buyers earned 1 coin per INR spent, redeemable at checkout (100 coins = 1 INR).
- This drove higher retention and repeat purchases.
Key Engineering Challenges
1. High-Performance Video Streaming
- Solution: Built on WebRTC with TURN servers for fallback connections, ensuring minimal disruption during NAT traversal.
2. Secure Payments
- Solution: Razorpay was integrated with additional encryption layers. COD workflows used a trust escrow system where funds were held until buyer satisfaction was confirmed.
3. Scalability
- Solution: Kubernetes enabled horizontal scaling, while Prometheus and Grafana monitored system performance and identified bottlenecks during peak usage.
Results and Impact
Buyer Engagement:
- RTO rates were reduced to less than 1% due to COD and accountability features.
- Video-supported products achieved a 3-3.5x higher conversion rate.
Seller Success:
- Over 200 sellers made 5+ sales within 6 months, with 63 sellers seeing a 400% revenue increase.
- Live sales contributed 62-65% of total sales, with ticket sizes 36-38% higher than offline purchases.
Operational Efficiency:
- Microservices ensured downtime during deployments was minimized, enabling continuous updates.
- Sellers received detailed insights, driving better decisions and engagement strategies.
Conclusion
Leo Network redefined social commerce by integrating real-time video engagement, robust system architecture, and thoughtful UX design. The platform’s modular microservices, secure workflows, and actionable analytics enabled a seamless and trustworthy experience for both buyers and sellers. This blend of engineering and product innovation exemplifies how modern commerce platforms can build scalable, impactful solutions.