Play&Buy

A store for foreign subscriptions, games and services in Belarus: a filtered catalogue, a cart, promo codes, orders with instant key delivery, reviews, and a substantial admin side.

The backend is Go: 55 files, 13,379 lines, 141 routes. The frontend is Next.js: 128 files, 26,384 lines.

The product here is a key, and it sits encrypted

A digital goods store is not built like a normal one: the warehouse holds activation strings, not boxes. A database leak in a store like this does not mean “customer addresses were stolen”, it means “the entire unsold stock was stolen”.

So keys are stored AES-encrypted and decrypted at the moment of delivery. The key warehouse is its own admin section with its own model: a key belongs to a product variant, is reserved against an order, and never returns to circulation once handed over.

Prices in local currency at today’s central-bank rate

Stock is bought in foreign currency and sold in Belarusian roubles. A rate typed in by hand starts lying the next day — and then either the store runs at a loss or the customer sees a price above the market.

The project runs a background worker that pulls the official USD and RUB rates from the National Bank’s API and updates them in the database. Catalogue prices are computed from the current rate, not from whatever the administrator last remembered.

The admin side is half the project

Fifteen sections, and none of it is “a product table with a delete button”:

• products, categories as a tree, variants with their own prices;
• the key warehouse and key movements;
• orders and their statuses;
• promo codes with expiry, usage limits and a minimum order value;
• review moderation — approve or reject;
• users, roles, blocking;
• an audit log of administrator actions — who changed what and when;
• monitoring, settings, FAQ, custom pages;
• a homepage builder and an appearance section.

The last two are worth calling out: the owner rearranges the blocks on the home page themselves, without going to a developer. For a store whose shop window is rebuilt for every sale, that is the difference between “I’ll get to it on Friday” and “done in five minutes”.

Support lives in Telegram, not in a separate panel

The store has a bot, and support runs through it: a customer sends /support, a ticket is created, and the conversation continues in Telegram — with statuses, assignment to an operator and the message history in the database.

The logic is simple and right: a buyer of digital goods is already in Telegram, and an operator does not need one more browser tab open. A person can only have one active ticket — otherwise the same problem spreads across three of them.

Why Go on the backend

141 routes, 23 tables, background workers, encryption, key delivery at the moment of payment. This is not the case where writing the first version fast matters most — what matters is predictable behaviour under load and strict typing on the boundary where money and stock meet.

The layers are separated: handlers, services, repositories, models. A handler never touches the database directly — the same discipline that later lets you change the storage without rewriting the logic.

What the buyer sees

A catalogue filtered by category, price, delivery type, rating and discounts, with search, sorting, two layouts and pagination. A product page with a gallery, variant selection, reviews and related items. A cart with promo codes and recalculation. Checkout with key delivery and activation instructions.

Reviews can be left without an account — otherwise a digital goods store, where half the purchases are made as a guest, would have no reviews at all.

How it runs

Six containers in one description: database, cache, backend, frontend, nginx and certificate issuing. Deploying to a clean server means cloning the repository, filling in the environment variables and bringing everything up with one command.

Go 1.22 · Fiber · GORM · PostgreSQL 16 · Redis 7 · Next.js 16 · React 19 · TypeScript · Tailwind CSS 4 · Docker · nginx