Luxor Bidding System

A full-stack bidding application built with Next.js, TypeScript, Prisma, and shadcn/ui.

Quick Start

Prerequisites

• Node.js 18+
• npm

Setup & Run

# Clone and install
git clone https://github.com/diegodscamara/luxor-bidding-system
cd luxor-bidding-system
npm install

# Setup environment
cp .env.example .env
# Then edit .env and update NEXTAUTH_SECRET with: openssl rand -base64 32

# Setup database
npx prisma generate
npx prisma db push
npm run db:seed

# Start application
npm run dev

Open http://localhost:3000

Authentication

• Sign up: Create a new account with name, email, and password
• Sign in: Use your email and password to access the application
• Password requirements: Minimum 8 characters with uppercase, lowercase, and number

Environment Variables

The application requires the following environment variables (see .env.example):

• DATABASE_URL: Database connection string (file:./prisma/dev.db for SQLite)
• NEXTAUTH_SECRET: Secret key for NextAuth (generate with openssl rand -base64 32)
• NEXTAUTH_URL: Application URL (http://localhost:3000 for development)
• NODE_ENV: Environment setting (development/production)

Features Implemented

✅ Complete Authentication: Email/password signup/signin with secure password hashing
✅ Dataset: 100 collections, 1000 bids, 10 users
✅ API Endpoints: All CRUD operations + accept/reject bids with proper validation
✅ Responsive UI: Mobile-first design with nested tables/cards for collections and bids
✅ Smart Forms: Create/update modals with field-specific error handling
✅ Authorization: Role-based permissions (owners vs bidders)
✅ Error Handling: Comprehensive validation with user-friendly messages

Architecture Questions

How would you monitor the application to ensure it is running smoothly?

For a production bidding system, I would implement monitoring at multiple levels:

Application Performance Monitoring:

• Tool: Implement Sentry for real-time error tracking and performance monitoring
  • Track API response times, especially for bid creation/acceptance (critical business flows)
  • Monitor error rates and categorize them (authentication, validation, database, network)
  • Set up alerts for error spike detection (>5% error rate triggers immediate alert)

Business Metrics Dashboard:

• Key Metrics to Track:
  • Bid success rate (accepted/total bids) - indicates system effectiveness
  • Average response time for bid operations (<200ms target)
  • User engagement metrics (bids per user, collection views)
  • Revenue-impacting errors (failed bid acceptances, payment processing issues)

Infrastructure Monitoring:

• Database Performance: Monitor Prisma query performance and connection pool usage
  • Track slow queries (>100ms) that could impact user experience during peak bidding
  • Set up alerts for database connection exhaustion
• Health Checks: Implement /api/health endpoint that verifies database connectivity and returns system status
• Logging Strategy: Structured logging with different levels (info for bid events, error for failures) without exposing sensitive data

Alerting Framework:

• Critical: Authentication system down, database unavailable (immediate notification)
• Warning: High response times, elevated error rates (alert within 15 minutes)
• Info: Daily/weekly reports on system performance and business metrics

How would you address scalability and performance?

For scaling this bidding system, I would focus on the most impactful optimizations first:

Database Optimization (Most Critical):

• Indexing Strategy: Create composite indexes on frequently queried combinations:

  INDEX idx_bids_collection_status ON bids(collection_id, status);
  INDEX idx_collections_owner ON collections(owner_id);

• Query Optimization: The current implementation already includes efficient queries with proper include statements to avoid N+1 problems
• Connection Pooling: Configure Prisma connection pooling (pool size: 20-30 connections) and implement connection retry logic

Caching Strategy:

• Redis Implementation: Cache frequently accessed data with appropriate TTL:
  • Collections list (5 minutes TTL) - reduces database load for main page
  • User sessions (30 minutes TTL) - improves authentication performance
  • Bid counts per collection (1 minute TTL) - reduces real-time calculation overhead
• Next.js Built-in Caching: Leverage ISR (Incremental Static Regeneration) for collection pages that don't change frequently

Application-Level Performance:

• API Rate Limiting: The current implementation includes basic rate limiting - enhance with Redis-based distributed rate limiting for production
• Background Processing: Move email notifications and analytics tracking to background jobs using Bull queue system
• Pagination Optimization: Current pagination is already implemented - optimize with cursor-based pagination for collections with >1000 items

Horizontal Scaling:

• Stateless Design: Current architecture is already stateless (JWT sessions) - ready for horizontal scaling
• Load Balancing: Deploy multiple Next.js instances behind a load balancer (AWS ALB/NGINX)
• Database Scaling: Implement read replicas for queries, keep writes on primary database

Monitoring Scalability: Set performance budgets (API responses <300ms, page loads <2s) and monitor compliance.

Trade-offs chosen and what I'd do with more time/resources

Current Implementation Decisions:

Security vs. Development Speed:

• Chosen: NextAuth with credentials provider for email/password authentication
• Trade-off: Faster implementation but limited to email/password only
• Production Improvement: Add OAuth providers (Google, GitHub) and implement 2FA for enhanced security. Add password reset functionality and email verification.

Database Choice:

• Chosen: SQLite for development simplicity and reviewer convenience
• Trade-off: Easy setup but limited concurrency and production scalability
• Production Improvement: Migrate to PostgreSQL with proper connection pooling, implement database migrations strategy, and add database backup/recovery procedures.

Real-time Features:

• Chosen: Traditional request/response pattern with manual refresh
• Trade-off: Simpler implementation but users don't see live bidding updates
• Production Improvement: Implement WebSocket connections for real-time bid updates, live notifications when bids are accepted/rejected, and real-time collection status changes.

Validation and Error Handling:

• Chosen: Comprehensive Zod validation with field-specific error messages
• Trade-off: Robust validation but potentially verbose error handling code
• Benefit: This was the right choice - provides excellent user experience and prevents data corruption

Additional Improvements with More Time:

Enhanced User Experience:

• Advanced Search: Full-text search across collection names/descriptions using database indexes
• Filtering System: Filter collections by price range, category, owner, bid status
• User Profiles: User dashboard showing bidding history, owned collections, success rates
• Email Notifications: Automated emails for bid acceptance, rejection, new bids on owned collections

Enterprise Features:

• Audit Logging: Complete audit trail for all bid operations (required for compliance)
• Bulk Operations: Allow bulk collection uploads, batch bid processing for enterprise users
• Advanced Analytics: Business intelligence dashboard with bidding trends, user behavior analysis
• API Documentation: Complete OpenAPI/Swagger documentation for third-party integrations

Development and Testing:

• Comprehensive Testing: Unit tests (Jest), integration tests (Playwright), API tests (Supertest)
• CI/CD Pipeline: Automated testing, security scanning, performance regression testing
• Code Quality: ESLint rules for security patterns, automated dependency vulnerability scanning