ποΈ System Architecture
SourceNet follows a microservices-oriented architecture that combines frontend, backend, blockchain, and decentralized storage layers.
Architecture Overview
βββββββββββββββ ββββββββββββββββ βββββββββββββββββ
β Frontend ββββββββββΆβ Backend ββββββββββΆβ SUI Blockchainβ
β (Next.js) β β (Express) β β (Move SC) β
βββββββββββββββ ββββββββββββββββ βββββββββββββββββ
β β
β β
ββββββΌβββββΌβββββ
β PostgreSQL β
β + Redis β
βββββββββββββββββ
β
ββββββΌβββββ
β Walrus β
β Storage β
βββββββββββKey Components
1. Frontend Layer (Next.js)
The user-facing application built with Next.js 14, featuring server-side rendering, client components for interactivity, and state management with Zustand.
- Pages: Marketplace, Seller Dashboard, Buyer Dashboard, Authentication
- Components: Reusable UI components with Tailwind CSS
- Hooks: Custom hooks for zkLogin, API calls, and blockchain interactions
- State Management: Zustand for global state (user, auth, purchases)
2. Backend API (Express.js)
RESTful API server handling authentication, data processing, and blockchain integration.
- Controllers: Auth, Seller, Buyer, Review, AI
- Services: Blockchain, Storage, Encryption, Cache, AI
- Middleware: JWT authentication, rate limiting, validation
- Job Queue: BullMQ for background processing (data encryption, fulfillment)
3. Database Layer (PostgreSQL)
Relational database for storing user data, DataPod metadata, purchases, and reviews.
| Table | Purpose |
|---|---|
| users | User profiles, SUI addresses, zkLogin salts |
| datapods | Dataset metadata, pricing, Walrus blob IDs |
| purchases | Purchase records, transaction digests, status |
| reviews | Ratings and comments from buyers |
| escrow_transactions | Escrow records and payment tracking |
4. Cache Layer (Redis)
In-memory cache for session management, rate limiting, and temporary data storage.
- Sessions: JWT tokens and user sessions
- Rate Limiting: API request throttling per user/IP
- Caching: Frequently accessed DataPod metadata
- Download Tokens: Temporary signed URLs for data downloads
5. Blockchain Layer (SUI)
Smart contracts written in Move language handle on-chain logic and asset management.
- DataPod Module: Create and manage DataPod objects
- Purchase Module: Handle purchase requests and payments
- Escrow Module: Lock and release funds securely
- Events: Emit events for indexer synchronization
6. Storage Layer (Walrus Protocol)
Decentralized storage for encrypted data files using erasure coding and distributed nodes.
- Publisher: Upload encrypted data and receive blob IDs
- Gateway: Retrieve data from distributed storage nodes
- Erasure Coding: Split data into redundant chunks
- High Availability: Data accessible even if some nodes fail
7. Real-time Layer (WebSocket)
WebSocket server for live updates and notifications.
- Purchase Notifications: Alert buyers when purchases complete
- Marketplace Updates: Real-time DataPod listings
- Seller Alerts: Notify sellers of new purchases
8. Indexer Service
Background service that synchronizes blockchain events with the database.
- Event Polling: Query SUI blockchain every 5 seconds
- Event Processing: Parse and store on-chain events
- Checkpoint Tracking: Track last processed block
- Database Sync: Update local database with blockchain state
Data Flow Diagram
π Complete Data Flow
User Browser
β
β (1) HTTP/HTTPS
βΌ
Next.js Frontend
β
β (2) REST API + WebSocket
βΌ
Express.js Backend
β
ββββ (3) SQL βββββΆ PostgreSQL
β
ββββ (4) Cache βββΆ Redis
β
ββββ (5) Upload ββΆ Walrus Storage
β
ββββ (6) TX ββββββΆ SUI Blockchain
β
β (7) Events
βΌ
Indexer Service
β
ββββΆ PostgreSQLSecurity Architecture
Authentication Security
- zkLogin: Zero-knowledge proofs for privacy-preserving authentication
- JWT Tokens: Signed tokens with 7-day expiration
- Salt Storage: Unique salts per user stored securely
Data Security
- AES-256 Encryption: All data encrypted at rest
- Per-Purchase Encryption: Unique encrypted copy per buyer
- Key Management: Encryption keys stored separately from data
Network Security
- HTTPS Only: All communication encrypted in transit
- Rate Limiting: 20 requests/min per user, 100/min per IP
- Input Validation: Zod schemas for all API inputs
Scalability Considerations
| Component | Scaling Strategy |
|---|---|
| Frontend | CDN distribution, static generation, edge caching |
| Backend API | Horizontal scaling with load balancer, stateless design |
| Database | Read replicas, connection pooling, query optimization |
| Cache | Redis cluster with sharding |
| Storage | Walrus naturally distributed across nodes |
| Job Queue | Multiple workers, priority queues |
β¨ Next Steps
Explore the Tech Stack for detailed technology information, or dive into Authentication to understand the zkLogin flow.