← Back to Home
Websites & platforms

NowlSoft E-Ticaret

E-commerce platform on a Go microservice architecture

My own capstone project for the NowlSoft internship

GogRPCRabbitMQRedisPostgreSQLDockerNext.js

Screenshots & Schematics

Microservices ArchitecturegRPC · RabbitMQ · Redis · Postgres
Clients / FrontendNext.js / MobileAPI GatewayJWT & Role AuthOWASP BOLA GuardAuth & User ServiceGo · gRPC · TokenProduct & CatalogGo · gRPC · Atomic LocksOrder & PaymentPCI-DSS Mask · GoRabbitMQ Event-Driven Message BusAsynchronous Audit, Notifications & Order EventsPostgreSQL (6x)DB-per-ServiceRedis CacheHot Reads / Wishlist

Problem & Challenge

Single points of failure (SPOF), database locking bottlenecks, and security vulnerabilities like BOLA/IDOR in traditional monolithic e-commerce platforms under high traffic.

How It Works

01

Client requests enter through an API Gateway with strict JWT validation and role enforcement.

02

Synchronous service-to-service calls run over high-performance gRPC over HTTP/2.

03

Order events, payment confirmations, and audit logging stream asynchronously through RabbitMQ message queues.

04

Frequently accessed product catalogs and user wishlists are cached in Redis to offload the primary database.

05

Payments undergo PCI-DSS card masking, while inventory transitions enforce atomic database locking.

Architecture & Technical Decisions

Eight Go microservices (Auth, Product, Order, Payment, Cart, Shipping, Notification, Audit) operating across six isolated PostgreSQL instances under the Database-per-Service pattern, with gRPC, RabbitMQ, Redis, and Docker Compose orchestration.

Eight microservices over six isolated databases following the database-per-service principle. Low-latency service-to-service calls run over gRPC, while notification and audit flows are event-driven over RabbitMQ. Security covers OWASP Top 10 BOLA/IDOR protection, PCI-DSS card masking and atomic database locks; a Redis-backed wishlist keeps hot reads off the database entirely.