Data Platform

● Live in production

Phone Vault

Bulk phone-number dedup & vendor-delivery tracking

~1M-row uploads

Layered Go architecture

Three-tier dedup pipeline

Overview

Phone Vault is a data-operations platform built by eSparks IT Solutions to turn bulk vendor CSV and Excel uploads into one clean, deduplicated phone-number master list. A Go/Gin API normalizes every number to real E.164 format with a genuine phone-number parsing library, then runs a three-tier deduplication check — within the uploaded file, against the master dataset, and against what that vendor has delivered before — before anything is migrated out of staging. The Next.js dashboard covers upload, staged review, vendor management, and date-ranged per-vendor reporting with CSV export. The stack is intentionally simple: a single Go API, a single Next.js frontend, and PostgreSQL as the only datastore, run via Docker Compose behind Nginx.

A folder of vendor CSVs isn't a clean phone list.

The same number arrives twice.

Without cross-referencing against what was already delivered, a vendor gets credited again for a number they sent last month.

Formatting is never consistent.

One file has +91, another has a leading 0, another has spaces — comparing numbers as plain strings misses obvious duplicates.

Nobody can prove what was reviewed.

Without a staging step, duplicate or bad rows get mixed into the master list with no way to tell which upload they came from.

A dedup pipeline that doesn't actually normalize phone numbers first isn't a dedup pipeline — it's a false sense of security.

Why it matters

The outcomes that actually move the needle

Three-tier dedup, not one.

Within-file, against the master list, and against what a vendor has already delivered — each checked separately.

Real E.164 normalization.

Built on a genuine phone-number parsing library, not a strip-non-digits shortcut, so formatting differences never hide a duplicate.

Nothing skips staging.

Every upload is categorized before it can reach the master table, and migration into it is an explicit, reviewable action.

Handles real file sizes.

Chunked, cancelable uploads and extended request timeouts, sized for uploads in the hundreds of thousands of rows.

Vendor accountability built in.

A per-vendor report shows exactly how many of their delivered numbers were actually new.

Key Capabilities

What we designed, built and shipped

Bulk CSV & Excel upload, chunked and cancelable, with real-time progress

Real E.164 phone normalization (libphonenumber), not string stripping

Three-tier dedup: within-file, against master, against vendor history

Staging → master review flow with per-vendor duplicate/dispute reporting

Technology Stack

Every choice made for a reason — not just what's trendy

Layer	Technology	Why
API	Go 1.25 + Gin	Low-memory footprint for high-volume file processing
Web	Next.js 15 + React 18	Dashboard for uploads, review, vendors and reports
Database	PostgreSQL 17	Single datastore; schema applies idempotently on boot
Phone parsing	libphonenumber (Go port)	Real E.164 normalization, not string stripping
Excel handling	excelize	Genuine .xlsx parsing, converted to CSV before processing
Auth	JWT access + refresh tokens over bcrypt	Stateless sessions sized for an internal tool
Deployment	Docker Compose, Nginx-fronted	Containers bind to localhost only in production
Logging	zap (structured, Go)	Structured logs instead of unstructured console output

Architecture

A simple pipeline, on purpose

One API, one database — every upload is normalized and checked in three passes before it can reach the master table.

Phone Vault architecture diagram: users on a phone or desktop browser reach the Next.js 15 / React 18 web dashboard over HTTPS to upload phone lists, review duplicates and view reports. The dashboard calls the Go 1.25 + Gin API over HTTPS (REST) with JWT access and refresh tokens; passwords are hashed with bcrypt. The API talks SQL over a private network to PostgreSQL 17, which holds the master table, staging tables and vendor delivery history, with the schema applied idempotently on boot. Inside the API, each upload goes through a pipeline: 1) upload a CSV, Excel or text file, 2) normalize numbers to E.164 with libphonenumber, 3) three deduplication passes — within the uploaded file, against the master list, and against that vendor's delivery history — and 4) store only unique, normalized numbers in the master table. Key characteristics: one API and one database with no cache, queue or third-party service; HTTPS, JWT and bcrypt; accurate E.164 numbers; three-tier dedup; upload, review and detailed reports on the dashboard; and an auto-applied schema.

Every uploaded file is parsed in-process, normalized to E.164, and run through the three-tier dedup pipeline before anything touches the master table in PostgreSQL — the product's only datastore.

How it works

From a vendor file to a clean master list

Upload a vendor file

CSV or Excel, in parallel chunks, with cancelable progress.

Numbers get normalized

Every number is parsed to E.164 before anything else happens.

Three dedup checks run

Within-file, against master, against that vendor's history.

Review in staging

Results are categorized as unique, self-duplicate, master-duplicate or vendor-duplicate.

Migrate to master

Reviewed unique rows move into the authoritative list, individually or as a group.

Report and export

Pull a per-vendor report or export any result set to CSV.

Deployment

How it runs

Self-hosted via Docker Compose.

The API, web app and database each run in their own health-checked container, with production containers bound to localhost behind an Nginx TLS reverse proxy.

Operational details

Docker Compose — API, web and Postgres each in their own health-checked container
Idempotent schema-on-boot — no separate migration step to run or forget
Standalone CLI tools: a phone-number backfill/normalize utility and a one-time legacy-database migrator
Extended request timeouts and a slowloris guard, sized for large file uploads

See the dedup pipeline on real vendor files.

We'll walk through an upload, the three-tier dedup, and a vendor report — on a call.

Request a demo

Complete feature guide

Everything the platform does

Phone Vault turns a folder of vendor CSV and Excel exports into one clean, deduplicated master list — with a record of who delivered which number, and whether it was actually new. Here is everything the platform does.

Ingestion & dedup

From raw vendor files to a clean master list

Bulk upload, real phone normalization, and three-tier deduplication — nothing reaches the master table without being checked.

Bulk upload

Chunked, cancelable uploads. Large CSV and Excel files upload in parallel chunks with live progress, and a running upload can be canceled mid-flight.
Real Excel parsing. Uploaded workbooks are converted and parsed with a real Excel library, not assumed to already be CSV.

Three-tier deduplication

Within-file duplicates. Repeats inside the same upload are caught before anything is written.
Against the master list. Every number is checked against the authoritative, deduplicated master dataset.
Against vendor history. A per-vendor delivery index remembers what each vendor has already sent, so re-deliveries are flagged, not re-billed.

Real phone normalization

E.164 everywhere. Numbers are parsed and normalized with a real phone-number library, not a strip-non-digits shortcut.
Backfill tool. A standalone CLI can re-normalize existing records if formatting rules change.

Staging → master review

Nothing skips review. Every upload lands in staging first, categorized as unique, self-duplicate, master-duplicate or vendor-duplicate.
Explicit migration. Reviewed rows move into the master table individually or as a group — never silently.

Vendor & operations

Know who sent what

Vendor-level reporting, search, and the day-to-day admin tools a data-operations team actually needs.

Vendor tracking

One record per vendor. Vendor master data ties every delivered number back to who sent it.
Delivery memory. A per-vendor phone index is the source of truth for whether a vendor has sent a number before.

Reporting & export

Date-ranged vendor reports. Unique, self-duplicate, master-duplicate, vendor-duplicate and error counts, per vendor, over any date range.
CSV export. Reports and result sets both export to CSV for downstream use.

Search & discovery

Field discovery. Search across the fields actually present in an uploaded file, not a fixed schema.
Per-file search. Look up specific records inside a specific upload result.

User management

Full admin control. Admins can create, update, lock, unlock, activate or deactivate user accounts.
Role-aware dashboard. The dashboard adapts what it shows based on admin vs. standard-user role.

Storage maintenance

Admin-triggered compaction. A maintenance job reclaims storage without needing a maintenance window.
Configurable limits. Upload size and file-extension allow-list are admin-configurable.

Security & privacy

Passwords hashed with bcrypt; the hash is never returned in API responses.
Configurable upload size and file-extension allow-list, enforced server-side.
Security response headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) on every page.
Production containers bind to localhost only, behind Nginx TLS termination — the database port is never exposed publicly.
Stateless JWT auth with a short-lived access token and a separate refresh token.

Reliability

Health-checked containers so the API and database are monitored automatically.
Idempotent schema-on-boot — the database schema applies safely on every start, with no manual migration step to forget.
Sized for large uploads: extended request timeouts and a slowloris guard on every connection.
A standalone normalize tool can backfill phone-number formatting across existing data without downtime.

Ready to Start Your Project?

Let's discuss how we can help you achieve similar results for your business

Get in Touch Our Services