02 / Early Thinking
Planning sketches and
architecture notes
Before I wrote any code, I started by sketching some thoughts down on how I wanted to develop this solution. Here are some pictures from my notebook:
A backend that turns the social graph into real-world group plans. The atomic unit is a plan seed: a venue, a group, and a time. The system scores it, propagates it, and books it.
The core problem is simple: the app only works if enough people show up at the same place. But if you just blast generic recommendations, nobody feels like the plan is theirs. You need to manufacture plans that feel organic to each person while quietly concentrating demand for the venue. Recommendations scatter people. Promotions feel transactional. You have to make it feel like the plan happened naturally, even though the system orchestrated it.
Before I wrote any code, I started by sketching some thoughts down on how I wanted to develop this solution. Here are some pictures from my notebook:
Instead of recommending venues to individuals, the system generates plan seeds: a venue, a starter group of 2-3 people, and a time slot. Each seed has a conversion probability. Then it propagates through the social graph using greedy submodular influence maximization, picking the order of who to show the plan to so that the most people end up going. Who you ask first actually changes who says yes later.
Each model owns one piece of the pipeline. They're small, focused, and trained on interaction data from the social graph.
API requests go through FastAPI synchronously. Everything else (cascades, momentum checks, booking) is async through Redis Streams. The request path never blocks on ML inference or external API calls.
Six stages. Each one compounds the signal from the last. The whole point is that by the time you're asked to join, three of your friends already said yes.
| Technology | Role |
|---|---|
| Python 3.12 | Backend language, async-first with type hints throughout |
| FastAPI | API gateway with automatic OpenAPI docs and Pydantic validation |
| PostgreSQL + pgvector | Primary datastore with vector similarity search for embeddings |
| Redis | Event bus (Streams), caching, and real-time state management |
| PyTorch | Model training and inference for all ML components |
| PyTorch Geometric | Graph neural network layers (LGConv) for SocialLGN |
| NetworkX | Social graph analysis, influence maximization algorithms |
| Next.js 14 | Frontend with App Router, server components, and streaming |
| Tailwind CSS | Utility-first styling for the mobile-first demo UI |
| Framer Motion | Physics-based animations for feed transitions and interactions |
| Vapi | Voice AI for outbound booking calls, integrated via HTTP API |
| D3-force | Force-directed graph layouts for propagation cascade visualization |
Every system is a set of bets. These are the ones I made and why.
This system runs on 200 users and 50 venues. At production scale, the main bottlenecks would be influence maximization (NP-hard, needs approximate methods), embedding recomputation (batch vs online training tradeoff), and event throughput (Redis Streams to Kafka). These are known problems with known solutions. The architecture was designed with them in mind.