cannabis-delivery-platform-scale@drop-delivery:~/case-study

Cannabis Tech / E-commerce 12 months 2020-2021

Cannabis Delivery Platform Scale

@ Drop Delivery — Senior Software Engineer

Building the backend that processed $30M+ in orders across 6 states and 3 provinces

$30M+ Orders Processed

354% YoY Growth

228K+ Deliveries

$ cat PROBLEM.md

Explosive Growth Met Legacy Infrastructure

Drop Delivery was experiencing hockey-stick growth — expanding to new states monthly, onboarding dozens of dispensaries, processing thousands of orders daily. The legacy PHP codebase and database weren't designed for this scale.

Key Challenges:

🔴 Database queries that were fine at 100 orders/day were crushing servers at 10,000
🔴 Each new state had different regulatory requirements — compliance was a constant scramble
🔴 Real-time delivery tracking lagged during peak hours, frustrating customers
🔴 Scaling horizontally was difficult due to monolithic architecture

$ cat SOLUTION.md

Performance Optimization + Configuration-Driven Compliance

Rather than a risky rewrite, we optimized the existing system strategically. Database indices, query optimization, caching layers, and a configuration-driven compliance system that made multi-state expansion painless.

Technical Approach:

Database Performance Overhaul

Added proper indexing, implemented read replicas for tracking queries, and introduced Redis caching for frequently accessed data.

Configuration-Driven Compliance

Built a rules engine that abstracted state-specific regulations. Adding a new state became configuration, not code changes.

Real-Time Tracking Optimization

Separated read and write paths for delivery tracking. Hot data in Redis, historical data in MySQL.

Frontend Modernization

Migrated critical flows from jQuery to React for better UX and maintainability.

$ cat tech-stack.json

🚀 Core Technologies

PHP 7

Backend application

Why: Existing codebase — optimized rather than rewrote

MySQL

Primary database

Why: Established, well-understood, with excellent tooling

React

Modern frontend components

Why: Better UX for complex order flows

🔧 Supporting Technologies

Redis AWS RDS CloudFront CloudWatch

☁️ Infrastructure

AWS EC2 AWS S3 Load balancer

$ man implementation-details

Database Optimization Strategy

The original database had grown organically without proper indexing. Our approach:

1. Query Analysis Used MySQL slow query log to identify the worst offenders. Top 10 queries were responsible for 80% of database load.

2. Index Strategy Added composite indexes for common query patterns:

1
2
3
4
5
6
7
-- Orders by dispensary and status (common dashboard query)
CREATE INDEX idx_orders_dispensary_status 
ON orders(dispensary_id, status, created_at DESC);

-- Delivery tracking (most frequent read)
CREATE INDEX idx_deliveries_active
ON deliveries(status, driver_id, scheduled_time);

3. Read Replicas Tracking queries went to read replicas. Write path stayed on primary. This alone reduced primary load by 60%.

4. Redis Caching Hot data (active orders, driver locations) cached in Redis with 30-second TTL.

Multi-State Compliance Engine

Cannabis regulations vary wildly by jurisdiction. Instead of code changes per state:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
// State-specific rules as configuration
$stateRules = [
    'CA' => [
        'max_order_weight' => '28g',
        'delivery_hours' => '8:00-22:00',
        'id_verification' => 'required',
        'excise_tax_rate' => 0.15,
    ],
    'CO' => [
        'max_order_weight' => '28g',
        'delivery_hours' => '8:00-20:00',
        'id_verification' => 'required',
        'excise_tax_rate' => 0.15,
    ],
    // ... more states
];

The compliance engine applied these rules at checkout, reporting, and delivery. Adding a new state meant adding a configuration block, not code.

$ echo $RESULTS

354% Growth Without Major Architecture Changes

$30M+ Total Orders Processed In 17 months

354% Year-over-Year Growth Supported by infrastructure

6 States + 3 Provinces Geographic Expansion Using config-driven compliance

65 Client Dispensaries On the platform

Additional Outcomes:

✓ Database query times reduced by 80% through proper indexing
✓ New state launches reduced from weeks to days
✓ Zero downtime during Black Friday-level traffic spikes

$ cat LESSONS_LEARNED.md

Optimize Before Rewriting

The PHP codebase everyone wanted to rewrite handled 10x scale with targeted optimizations. Rewrites are expensive and risky — optimize first.

Configuration-Driven Design Enables Velocity

Making regulatory compliance configuration-driven meant product could launch new states without waiting for engineering.

Separate Hot and Cold Data Paths

Real-time tracking doesn't need historical queries. Separating read/write paths for different access patterns solved our scaling issues.

$ cat README.md

The Growth Challenge

When I joined Drop Delivery, the company was processing maybe 500 orders per day. By the time I left, we were processing 5,000+. That 10x growth didn’t happen gradually — it came in spurts as we expanded to new states and signed major dispensary chains.

The infrastructure wasn’t ready. Neither was anyone else at that growth rate.

Why We Didn’t Rewrite

The first instinct when you see a legacy PHP codebase is to rewrite it in something “modern.” We resisted.

Reasons we optimized instead:

Velocity: A rewrite would take 6+ months. The business couldn’t wait.
Risk: Rewrites often introduce as many bugs as they fix.
Reality: PHP 7 is actually fast. The problem was implementation, not language.

With targeted optimizations, we achieved 10x scale without changing the core architecture.

The Technical Work

Database: From Slow to Fast

The database was the primary bottleneck. Queries that took 50ms at 100 orders/day were taking 5 seconds at 10,000.

Step 1: Find the Problems Enabled slow query log, identified the top 10 worst queries. Together they represented 80% of database load.

Step 2: Add Proper Indexes The original schema had almost no indexes beyond primary keys. We added composite indexes for common query patterns.

Before: SELECT * FROM orders WHERE dispensary_id = X AND status = 'pending' → 3 seconds After: Same query with composite index → 15 milliseconds

Step 3: Separate Read and Write Real-time tracking queries (where’s my delivery?) were hammering the same database as order processing. We added MySQL read replicas and routed tracking queries there.

Primary database load dropped 60% immediately.

Step 4: Cache Hot Data Active orders, driver locations, inventory levels — data accessed constantly but changing infrequently. Redis cache with 30-second TTL reduced database hits by 40%.

Compliance: Configuration, Not Code

Cannabis is regulated differently in every state:

California allows 28g per order
Colorado has different delivery hours
Nevada requires different reporting

Initially, each state was a code branch. Nightmarish to maintain.

We built a compliance engine that consumed configuration:

1
State config → Rules engine → Applied at checkout/delivery/reporting

Adding Oregon after that? Create a config file, test, deploy. Days, not weeks.

Frontend: Selective Modernization

The entire frontend didn’t need to be React. But the order flow — the critical path — did.

We migrated:

Order creation
Checkout
Delivery tracking

From jQuery spaghetti to React components. This improved:

Page load times (code splitting)
User experience (reactive updates)
Developer velocity (component reuse)

The rest of the admin stayed jQuery. It worked, and touching it wasn’t worth the risk.

Results

Quantitative:

$30M+ in orders processed
354% year-over-year growth supported
6 US states + 3 Canadian provinces
65 dispensary clients on platform

Qualitative:

Zero downtime during peak shopping periods (4/20, Black Friday)
New state launches in days instead of weeks
Engineering team could focus on features, not fires

Takeaways for Growth Engineers

1. Optimize Before You Rewrite

The “rewrite in Rust” fantasy is usually just that. Targeted optimization of existing code is faster and safer.

2. Indexes Are Not Optional

Proper database indexing should happen during initial development. Retrofitting is painful but necessary.

3. Configuration-Driven Design Scales Organizations

When business logic is configuration, product teams can move without engineering bottlenecks.

4. Separate Hot and Cold Paths

Real-time data and historical data have different access patterns. Design accordingly.

Scaling a high-growth platform? Let’s talk optimization strategies.

Experience: Senior Software Engineer at Drop Delivery

Technologies: PHP Development, React Development, AWS Architecture, Redis Caching

Scaling Your E-commerce Platform?

Let's discuss how I can help solve your engineering challenges.

📅 Schedule a Call 📧 Send Email