ReachInbox – Email Job Scheduler

• https://www.loom.com/share/16e375f28d53486f9e35f73ff69d3c18

Quick Links

• Quick Start with one Command
• Frontend Application Setup
• Backend Service Setup
• Architecture & Core Design
• Tech Stack

Quick Start

1. Clone Repository

git clone https://github.com/rajathshttgr/Inbox.git
cd Inbox

2. Run Quick Start Script

chmod +x quickstart.sh
./quickstart.sh

3. Access Applications

• Frontend: http://localhost:3000
• Backend: http://localhost:4000

Frontend Application Setup

1. Clone Repository

git clone https://github.com/rajathshttgr/Inbox.git
cd Inbox/frontend

2. Install Dependencies

npm install

3. Environment Variables

Copy the .env.example file and update if needed:

cp .env.example .env

Update NEXT_PUBLIC_SERVER in .env if required.

4. Run Locally

npm run dev

Server will run at:

http://localhost:3000

---

Backend Service Setup

Prerequisites

• Node.js (v18+ recommended)
• PostgreSQL
• Redis
• Docker Compose (v2+)

1. Clone Repository

git clone https://github.com/rajathshttgr/Inbox.git
cd Inbox/backend

2. Run Redis & Postgres in background

docker compose -f docker-compose.yml up

3. Configure environment variables

cp .env.example .env

Make sure .env uses localhost DB URLs.

4. Install dependencies

npm install

5. Run Prisma migrations

npx prisma migrate dev

6. Start the server

npm run dev

Server will run at:

http://localhost:4000

Architecture & Core Design

1. Email Scheduling

• Each recipient email is stored as a row in EmailJob.

• Jobs are enqueued into BullMQ with a delayed execution:

  delay = scheduledAt - currentTime
  

• BullMQ persists delayed jobs in Redis, ensuring:

  • Future emails are sent correctly after server restarts
  • Jobs are not duplicated or restarted

2. Concurrency Control

• Worker concurrency is configurable via config/env.ts:

export const worker = {
  concurrency: 10,
  delayBetweenEmail: 2,
  hourlyLimit: 500,
};

• Multiple jobs can be processed in parallel safely using BullMQ workers.

3. Hourly Rate Limiting & Email Throttling

• Campaign-level limits

  • Hourly limit and delay between emails are configurable at compose time.
  • Default values are applied when not explicitly provided.
  • Limits are applied during initial scheduling.

• User-level hourly limits

  • Configurable via environment variables.
  • Enforced at send time using Redis atomic counters (Lua).
  • When limits are exceeded, jobs are rescheduled into the next available hour window instead of failing.

Tech Stack

Backend

• Node.js + TypeScript
• Express
• Prisma ORM
• PostgreSQL
• Redis + BullMQ
• Google OAuth
• Ethereal SMTP
• Docker

Frontend

• Next.js + TypeScript
• Tailwind CSS