Full-Stack E-Commerce Platform

Seven modules, three layers

I organised the backend under internal/modules/, with each module split three ways. The rules keep HTTP handling, business decisions and storage separate:

Layer	Rule	Role
Handler	"No business logic or database queries are allowed here."	Parses, validates, returns JSON
Service	"No knowledge of HTTP or raw SQL queries."	Business rules, coordinates repositories
Repository	"Only deals with Database models and returning data to the Service."	All GORM queries

CartService shows why I used this separation. It is injected with both a Redis and a PostgreSQL repository, and routes on whether the caller is authenticated:

type CartService struct {
	redisRepo    CartRepository   // guest carts
	postgresRepo CartRepository   // authenticated carts
	productRepo  *product.ProductRepository
}

if userID != "" {
    return s.postgresRepo.AddItem(ctx, userID, item)
}
return s.redisRepo.AddItem(ctx, guestID, item)

The handler never learns which store was used. On login the guest cart is merged into the user's, so the redirect is not visible to the client either.

Refresh-token rotation and concurrent requests

Rotation has two separate concerns: ensuring that only one request can use a valid token, and deciding how to respond when a revoked token is presented again.

Refresh tokens are opaque, 32-byte hex, stored only as a SHA-256 hash, held in an HttpOnly cookie, and rotated on every single use. Each new token records the token that created it, which builds a chain:

RT1 ──▶ RT2 ──▶ RT3 ──▶ RT4
 ✗        ✗        ✗       ✓ current
 revoked  revoked  revoked

When a refresh arrives, the service hashes it and looks it up. If the token exists and is already revoked, someone is replaying it, and the response depends on one thing:

if storedToken.IsRevoked {
    if time.Since(storedToken.CreatedAt) < 2*time.Second {
        return "", "", errors.New("concurrent refresh detected, please retry")
    }
    _ = s.repo.RevokeUserTokens(storedToken.UserID.String())
    return "", "", errors.New("security alert: token reuse detected")
}

The window is measured from the token's created_at, not from when it was revoked. So the check is really "is this token younger than two seconds old?". That is worth stating precisely, because it is not the same question as "was this revoked in the last two seconds?".

This is a limited heuristic, not proof of whether reuse is benign or malicious. Two legitimate refresh requests can arrive milliseconds apart for a token that was issued hours ago. If the second request reads it after revocation, the age check takes the theft-alert path and revokes every session for that user. Conversely, replay of a newly issued token can fall inside the retry window.

There is a third layer that the project's own architecture documentation does not describe. Only the journal does. Revocation is a conditional update, and the row count decides the race:

UPDATE refresh_tokens SET is_revoked = true WHERE id = ? AND is_revoked = false

RowsAffected == 1 means this request won and may mint a new token. 0 means another request revoked it after this request read it as valid; this path returns the concurrent-refresh error without revoking all sessions. The conditional update prevents multiple requests from winning rotation for the same token. It does not remove the false-positive risk in the earlier already-revoked branch. The concurrency test makes the single-winner behaviour measurable:

	HTTP 200	HTTP 401	Live tokens
Before	4	6	4
After	1	9	1

Ten goroutines released from a barrier against one token. Four simultaneous refreshes each minting a live token is the bug; one winner is the correct answer.

Client-side triggers and test timing

The journal records a client-side false positive and a test-timing issue:

• React 18 Strict Mode double-mounts useEffect in development, firing two refreshes. The backend read the second as a replay and revoked every session, because the code classified the second request as theft. A refreshPromise singleton in AuthContext prevented duplicate refreshes from that client path; it did not change the backend's age heuristic.
• The rotation test itself replayed inside the token-age window, so it took the retry path and failed. Fixed by backdating the test token's created_at by ten seconds.

Order transactions and stock locking

Isolation is where the concurrency work lives. Placing an order takes a pessimistic row lock:

clause.Locking{Strength: "UPDATE"}   // emits SELECT … FOR UPDATE

Two buyers racing for the last unit: one gets 201, the other 400. The transaction covers stock deduction, the order row, the order items and the cart clear together, so a failure at any point leaves none of them applied.

Payments do not wait for Stripe

POST /payments validates the order and returns 202 Accepted immediately, publishing to RabbitMQ. A worker consumes, calls Stripe, updates the order and sends the email. Two separate AMQP channels keep publishing from blocking on the consumer, and manual acknowledgements mean an unacked message is redelivered rather than lost.

Encryption at rest

Exactly two columns, both on orders, both AES-256-GCM through GORM hooks. BeforeSave encrypts, AfterFind decrypts, so nothing above the model layer knows:

func (o *Order) BeforeSave(tx *gorm.DB) error {
    if o.ShippingAddress != nil {
        jsonBytes, _ := json.Marshal(o.ShippingAddress)
        encryptedAddr, _ := utils.Encrypt(string(jsonBytes))
        o.ShippingAddressEncrypted = encryptedAddr
    }
    if o.StripePaymentIntentID != "" {
        o.StripePaymentIntentID, _ = utils.Encrypt(o.StripePaymentIntentID)
    }
    return nil
}

That protection depends on selecting the correct key. The fallback below undermines it when the application is misconfigured.

The key fallback

During the later source review, I found a fallback the documentation did not describe:

if len(key) != 32 {
    // Fallback for dev, panic in prod
    return []byte("12345678901234567890123456789012")
}

The comment says it panics in production. It does not. It returns a hardcoded key that is published in the repository. A deployment that forgot ENCRYPTION_KEY would encrypt real shipping addresses with it, and nothing would fail loudly.

The same helper has a second problem. The guide says the key must be exactly 32 bytes base64-encoded, but openssl rand -base64 32 produces 44 characters. That would fail the length check and silently take the fallback path.

Load testing: correcting the workload

I corrected three problems in the load-test setup before treating latency as a useful result:

Run 1 is the trap. The p90 of 3.84 ms looks like a triumph until you read the check rate:

Ironically, the latency for successful requests was extremely low. However, this is because most requests were being rejected almost instantly.

The limiter was configured at 5 tokens/second, and the entire test came from one IP. Order placement succeeded 0 times out of 83.

In run 3, add-to-cart failed 405 times and order placement 420. Their sum matches the reported http_req_failed count of 825, supporting the diagnosis that these failures came from stock depletion rather than a separate, unexplained error spike.

Run 4: 100% checks, 0.00% failures, p90 of 50.52 ms against a 2,000 ms requirement, at 100 concurrent users.

Stress testing: latency under resource limits

Ramping 1 → 1,000 VUs over 12 minutes with the backend capped at 2 CPU cores and 1 GB. The rate limiter was raised to 5,000/s to reduce interference from the limiter:

Metric	Result
Max throughput	~104 req/s
p50 / p90 / p95	1.92 s / 8.90 s / 12.80 s
max	61.00 s
HTTP failures	5 of 77,551 (0.00%)

p95 failed the 5-second criterion. The report identifies several constraints:

• CPU pressure. The report attributes much of the slowdown to bcrypt during authentication and scheduling 1,000 concurrent routines on two cores. Its comparison with a roughly 400 req/s baseline has no raw output in the repository, so that comparison alone does not establish a CPU-only bottleneck.
• Zero 500s and zero dropped database connections at 12-second latency. The system stayed reliable while being far too slow, which is a different problem from the one the criterion measures.
• A hot row. Every one of the 1,000 users bought the same product id, so a single row was contended by the entire fleet and serialised by row-level locking.

The roughly 450 VU breaking point is read off the latency curve, not emitted as a dedicated capacity metric. Together with the shared-product workload, this limits how far I would generalise the result to other traffic patterns.

Why I left out catalogue response caching

I used Redis for guest carts but left the product catalogue without a Redis API response cache. The measured latency did not justify adding cache invalidation across filter combinations, especially where stale prices would affect correctness.

The original rationale also cited 95% bandwidth savings from HTTP caching. That figure was arithmetic on typical header sizes, not a captured byte-count metric. It is not a measured benefit. The documentation's cache-hit latency, database-load and memory figures are likewise projections for a cache that was not implemented.

Testing

99 test functions across 33 files: 86 integration, 13 unit. The integration tests run against real Postgres, Redis and RabbitMQ rather than mocks. That is why a race like the refresh-token one is caught by an assertion rather than by inspection.

The security-named tests are the ones worth naming: IDOR, XSS sanitisation, price tampering, rate-limiter header spoofing, concurrent refresh handling, and payment idempotency.

Other decisions

• VAT is snapshotted at purchase. A 25.5% rate is stored on the order and each line item, so changing the rate later cannot rewrite what a historic order cost.
• Password reset never confirms an account exists. The endpoint returns an identical 200 either way.
• Admin routes re-check the database. role = admin alone is not enough; is_2fa_enabled is read from the database on every request, so a token minted before 2FA was enabled cannot grant admin access.
• SetTrustedProxies(nil) means X-Forwarded-For is ignored outright for rate limiting, so the header cannot be used to evade it.
• Self-signed TLS is generated automatically when SERVER_PORT == 8443.