TutorPilot

Small coaching businesses stitch together video calls, spreadsheets, and shared drives. I built one system where an organisation signs up, defines its own roles, builds courses, runs them as scheduled batches, and teaches live classes that are recorded automatically.

The Go backend is split into modules (auth, admin, notification) behind a shared set of internal packages. Anything that must happen after a write, like sending a verification email, is stored as an event in the same Postgres transaction and relayed to Redis Streams afterwards, so the database and the side effects cannot drift apart.

1. 01

   Transactional outbox instead of dual writes

   Events are inserted in the same transaction as the business data. A relay claims them with FOR UPDATE SKIP LOCKED, so several relays can run without double-publishing.

2. 02

   Failures are kept, not dropped

   Consumers reclaim stalled messages with XAUTOCLAIM, classify errors for retry, and move poison messages to a dead-letter table that can be inspected and replayed.

3. 03

   A signing secret per tenant

   Each organisation has its own JWT secret, cached in Redis, so a token issued for one tenant cannot be verified by another.

• 74 REST endpoints with Swagger docs and 14 versioned migrations
• Schema-driven roles and privileges per organisation
• Courses, batches, tutor assignment, and student enrolment
• LiveKit classrooms with server-side recording to MinIO
• Shared file drive per batch on MinIO object storage

• Go
• PostgreSQL
• Redis Streams
• LiveKit
• MinIO
• Next.js

• 80 Go unit and integration tests, including outbox rollback behaviour