Rakamin Evermos: E-Commerce API

Overview

A backend service built with Go (Golang) implementing Clean Architecture. Developed as a final project for the Rakamin Academy × Evermos Virtual Internship, this API handles the complete e-commerce lifecycle: from authentication and multipart product uploads to atomic transactions and logistics mapping.

Post-internship, I re-opened the project for a major refactor, focusing heavily on system architecture, transaction security, and reliability under load.

swagger_ui

Architecture

The project strictly follows Clean Architecture to decouple business logic from external frameworks and infrastructure.

rakamin-evermos-backend-go/
├── app/          # Entry point and Graceful Shutdown handling
├── internal/
│   ├── core/     # Configuration, middleware, base models, utilities
│   └── domain/   # Business logic (Auth, Catalog, Checkout, Location, Shop)
├── tests/        # Unit & Integration test suites, Mocks
└── docs/         # PRD, OpenAPI schemas, Test Cases

Sacred Domain Rule: The internal/domain/ layer contains absolutely no test files (_test.go) or mocks. All testing mechanisms reside strictly within the tests/ directory to maintain architectural purity.

Core Engineering

The refactoring process introduced several critical mechanisms:

• Row Locking (Pessimistic Lock): Utilized SELECT ... FOR UPDATE during the checkout flow to strictly prevent overselling and race conditions when multiple users attempt to purchase the same inventory simultaneously.
• Idempotency & Snapshotting: Implemented MD5 Hash snapshotting for transaction logs. This ensures transaction history remains consistent without generating duplicate data, paired with X-Idempotency-Key headers to protect against double-click checkouts.
• Robust File Uploads: Applied Magic Bytes validation (JPEG/PNG/WEBP) and an HTTP MaxBytesReader 2MB limit. Implemented automated disk cleanup when products are soft-deleted, resulting in zero disk bloat.
• Randomized Jitter Cache: Integrated the EMSifa API for Indonesian regional data. The cache TTL is randomized (1-3 hours) to prevent cache stampede problems when fetching external data.
• Automated Testing: Wrote 21 modular Unit and Integration Test scenarios using testify, achieving 100% successful execution across the suite.

testing_suite

Conclusion

This refactoring phase reinforced that building a backend extends far beyond simply making features work. Long-term maintainability requires careful consideration of data consistency, defensive security practices, performance under load, and strict architectural boundaries.

Virtual Internship Completion Certificate