Best build on Vultr Cloud

[{“name”:“Best build on Vultr Cloud” “reason”:“Backend API hosting: Our plan was to deploy the Node.js + Express API layer on a Vultr VPS (Ubuntu 22.04) directly connected to MongoDB Atlas. This setup would have taken us beyond the limitations of no-code integrations ensuring always-on low-latency endpoints for listing and request management.

Containerized services: By packaging the catalog service and request/transaction service into Docker containers Vultr would have provided clean isolation without the overhead of heavyweight managed platforms. This approach would have let us scale specific microservices independently.

Automation bridge: Instead of relying solely on third-party workflows (which often hit free-tier limits) the VPS was intended to run a lightweight cron + worker service backed by a Redis-lite container. This worker would have ensured stale requests notifications and reputation updates were always processed — even if external services failed.

Security layer: Vultr would have acted as a secure proxy between the front-end and MongoDB Atlas preventing the client from directly hitting the database. That extra layer would have enforced field-level access rules and improved privacy for sensitive student data (emails contact info).

Scalability path: Our initial plan was to start with a small 1 vCPU/1 GB VPS for testing. With Vultr’s flexible scaling we could have seamlessly upgraded to larger instances or even distributed the load across multiple VPS behind a load balancer. This would have aligned perfectly with SwapShelf’s growth roadmap: start lean scale on demand.”} {“name”:“Best Use of MongoDB Atlas” “reason”:“nified data model: We designed SwapShelf around Atlas collections:

users (profile reputation college)

listings (books/notes edition tags ownerId status)

requests (listingId requesterId state machine)

transactions (audit of exchanges)

moderation (spam/review queue).
Atlas’s schemaless flexibility would have let us evolve these collections without painful migrations.

Atlas Search for discovery: Students rarely type exact titles; they search with partial names (“kurose networks 7e” “calculus PYQ”). With Atlas Search we planned to build fuzzy matching and autocomplete across title author and tags giving fast relevant results out-of-the-box without needing Elasticsearch.

Triggers and functions: Instead of maintaining background servers Atlas Triggers would have automated key workflows — closing stale requests incrementing reputation scores after transactions and sending notifications. This serverless automation would have reduced overhead while keeping workflows reliable.

Data governance via mongosh: We built all schema validation index creation and data hygiene scripts in mongosh. Our plan was to enforce field requirements (e.g. mandatory title type createdAt) and manage TTL indexes for auto-cleaning stale requests. mongosh also gave us quick analytics pipelines (e.g. number of exchanges per campus) without exporting data elsewhere.

Secure and scalable: With Atlas our front-end would never touch the database directly. All queries would go through a Node.js API layer or Atlas Data API ensuring field-level access control and preventing data leaks. Scaling would have been trivial — starting on M0/M2 and upgrading clusters as adoption grew without downtime.

Proof of intent: Even though the student plan was denied we still wrote the scripts schemas and queries in mongosh and designed our backend with Atlas in mind. On approval we could bootstrap a live cluster within minutes.”}]