Choosing the right store — twice
Card documents are nested and read-heavy; connections are relationship-heavy and queried by depth. Splitting them across MongoDB and Neo4j kept both fast, at the cost of coordinating writes across two databases.
All work
Digital business cards backed by a real social graph
SpingR
- Role
- Backend lead
- Year
- 2024
- Impact
- 10,000+ professionals · sub-200ms across 100k+ nodes
Overview
SpingR lets people design, share and manage digital business cards — but the interesting half is what happens after a card is shared. Every exchange becomes an edge in a Neo4j graph.
That turns networking questions into queries: who do we both know, who is two hops from this prospect, which introduction is shortest. In a document store those are guesses; in a graph they are traversals.
What I built
- Led the backend and chose the polyglot split — Neo4j for relationships, MongoDB for card content and media.
- Modelled the connection graph and wrote the traversal queries behind mutual-connection and path suggestions.
- Built JWT auth, card sharing flows and share-link handling.
- Added WebSocket notifications so a card scan or new connection surfaces immediately.
The hard parts
Keeping two databases honest
A connection touches both stores. Writes are ordered so the graph edge is only created after the card record commits, with a reconciliation pass that repairs any orphaned node left by a failed write.
Traversals that stay bounded
Unbounded friend-of-friend queries explode on well-connected users. Depth caps, indexed relationship types and result limits keep suggestion queries inside a predictable time budget regardless of network size.
Outcomes
- Connection discovery
- 2-hop
- Native relationships
- Graph
- Connection alerts
- Live
Stack
- Node.js
- Neo4j
- MongoDB
- WebSockets
- JWT
Live
Shipped as a mobile application — no public web URL