Executive Summary
This proposal outlines the development of a privacy-focused device identifier platform comprising a B2C portal (anonymous access), B2B portal (business users with RBAC), and administrative panel, backed by a high-performance Go API. The platform includes server-side generation and management of digital wallet passes (Apple Wallet & Google Wallet) and is designed for gradual scaling from an initial ~2,000 DAU to 50K+ DAU as marketing efforts ramp up.
01Proposed Architecture
High-Level System Design
graph TB
subgraph External["External Layer"]
CDN["CloudFlare CDN
Static Assets | DDoS | WAF"]
end
subgraph LoadBalancing["Load Balancing"]
LB["Load Balancer
Traefik / HAProxy"]
end
subgraph Frontend["Frontend Layer"]
B2C["B2C Portal
Remix SSR + shadcn/ui"]
B2B["B2B Portal
Remix + shadcn/ui"]
Admin["Admin Panel
Remix + shadcn/ui"]
end
subgraph Gateway["API Gateway"]
API["Go API Gateway
Rate Limiting | Auth | Routing"]
end
subgraph Services["Microservices"]
Core["Core API
Go + Chi"]
Notify["Notification Svc
Go Worker"]
Payment["Payment Svc
Go + Stripe"]
Wallet["Wallet Pass Svc
Apple + Google"]
end
subgraph Queue["Message Queue"]
MQ["RabbitMQ / AWS SQS"]
end
subgraph Data["Data Layer"]
DB[("PostgreSQL
Primary + Replicas")]
Cache[("Redis
Cache + Sessions")]
Logs[("Loki
Logs")]
Storage[("S3/MinIO
Reports")]
end
CDN --> LB
LB --> B2C
LB --> B2B
LB --> Admin
B2C --> API
B2B --> API
Admin --> API
API --> Core
API --> Notify
API --> Payment
API --> Wallet
Core --> MQ
Notify --> MQ
Payment --> MQ
MQ --> DB
MQ --> Cache
MQ --> Logs
MQ --> Storage
Technology Stack
| Layer |
Technology |
Rationale |
| Frontend |
Remix v2 (React) |
SSR for B2C SEO, no vendor lock-in, clean data loading |
| UI Components |
shadcn/ui + Tailwind |
Customizable, accessible, modern design system |
| Icons |
react-icons |
Multiple icon sets, tree-shakeable |
| State (Client) |
Zustand |
Lightweight, simple, TypeScript-first |
| Forms |
react-hook-form + Zod |
Performant validation, type-safe |
| Backend API |
Go + Chi + sqlc |
High performance, low memory, type-safe SQL |
| Database |
PostgreSQL 16 |
ACID compliance, JSON support, Serbian law compliance |
| Cache |
Redis |
Session storage, caching, rate limiting |
| Queue |
RabbitMQ |
Async processing, notifications, reports |
| Wallet Passes |
Apple PassKit + Google Wallet API |
Server-side pass generation, signing, push updates |
| Object Storage |
AWS S3 / MinIO |
Report storage, exports, pass assets |
| Monitoring |
Prometheus + Grafana + Loki |
Metrics, dashboards, centralized logging |
| CI/CD |
GitHub Actions + ArgoCD |
GitOps, automated deployments |
| Container |
Docker + Kubernetes |
Horizontal scaling, orchestration |
02Privacy-by-Design
graph LR
subgraph B2C["B2C User - Anonymous"]
B2C1["Session Token"]
B2C2["Device Fingerprint - hashed"]
B2C3["No PII stored"]
end
subgraph B2B["B2B User - Authenticated"]
B2B1["Email - hashed lookup"]
B2B2["Business Info"]
B2B3["Role/Permissions"]
B2B4["Audit Trail"]
end
subgraph Device["Device Identifiers"]
D1["IMEI/Serial Input"]
D2["SHA-256 Hash"]
D3["Stored Hash Only"]
end
D1 -->|"One-way hash"| D2
D2 -->|"Stored"| D3
B2C --> Device
B2B --> Device
Key Privacy Principles
- Device identifiers are hashed using SHA-256 before storage
- B2C users require no registration - fully anonymous lookups
- Only business-necessary data collected for B2B users
- Complete audit trail for compliance verification
03Security Architecture
Security is treated as a first-class concern across all layers, not as an afterthought. The platform implements defense-in-depth: every layer assumes the layer above it may be compromised, and applies its own controls independently.
Multi-Layer Security Model
- WAF (Web Application Firewall) with custom rulesets for API abuse patterns
- DDoS Protection (CloudFlare) — automatic mitigation for volumetric and application-layer attacks
- TLS 1.3 everywhere — no fallback to older protocols
- Strict CORS policies per portal (B2C, B2B, Admin on separate origins)
- Geo-blocking capability for admin panel (restrict to Serbian/EU IPs if required)
- Rate Limiting: Tiered by user type — 100 req/min (anonymous), 1,000 req/min (authenticated), custom limits per B2B organization
- Brute-Force Protection: Progressive backoff on failed auth attempts, account lockout after configurable threshold, CAPTCHA integration
- Antifraud Rules: Anomaly detection on lookup patterns (e.g. bulk sequential IMEI queries), automatic flagging and throttling of suspicious behavior
- JWT validation with short-lived access tokens (15min) + refresh token rotation
- Request sanitization and payload size limits
- IP reputation filtering with configurable blocklists
- OWASP Top 10 — systematic mitigations:
- A01 Broken Access Control — RBAC enforced at middleware level, endpoint-level permission checks
- A02 Cryptographic Failures — AES-256 at rest, TLS 1.3 in transit, no sensitive data in logs
- A03 Injection — sqlc parameterized queries (compile-time SQL safety), Zod input validation on frontend, Go validator on backend
- A04 Insecure Design — Threat modeling during discovery phase, security review in CI/CD
- A05 Security Misconfiguration — Infrastructure-as-Code (Terraform/Helm), automated security scanning in CI
- A06 Vulnerable Components — Automated dependency scanning (Dependabot/Snyk), regular update cycles
- A07 Auth Failures — Bcrypt password hashing, MFA support for admin/B2B, secure session handling
- A08 Data Integrity — Signed API responses for critical operations, CSP headers, SRI for static assets
- A09 Logging Failures — Structured logging with Loki, all security events captured, tamper-resistant audit trail
- A10 SSRF — Strict allowlisting for outbound requests, no user-controlled URL fetching
- Encryption at Rest — AES-256 for database, S3 server-side encryption for reports and exports
- Encryption in Transit — TLS 1.3 for all connections including internal service-to-service
- Field-Level Encryption for PII (B2B user emails, organization details)
- Key Management via AWS KMS or HashiCorp Vault — automatic key rotation
- Database connection encryption enforced (sslmode=verify-full)
- Secrets management — no credentials in code, environment variables via sealed secrets
- Role-Based Access Control with granular permissions:
- Super Admin: Full system access, user management, system configuration
- Admin: Organization oversight, report access, content management
- B2B Manager: Organization management, team member CRUD, billing, API key management
- B2B User: Scoped to assigned permissions within their organization
- Anonymous (B2C): Public endpoints only, rate-limited
- Audit Logging: Every mutation (create, update, delete) logged with actor, timestamp, IP, old/new values
- Session Management: Redis-backed sessions, 24h expiry, concurrent session limits, forced logout capability
- API Keys: Scoped API keys for B2B integrations, with per-key rate limits and IP whitelisting
Audit Trail & Accountability
All critical actions are logged immutably:
- Authentication events (login, logout, failed attempts, password changes)
- Data access and modifications (who accessed what, when, from where)
- Administrative actions (role changes, configuration updates, user management)
- System events (deployments, configuration changes, security incidents)
- Logs stored in append-only format with integrity checksums — retained per configurable policy (default: 2 years)
Backup & Disaster Recovery
- Database: Automated daily backups with point-in-time recovery (PITR), 30-day retention, cross-region replication optional
- Application State: Stateless services — recovery is a fresh deployment from container registry
- Recovery Targets: RPO < 1 hour, RTO < 4 hours (Standard SLA), RTO < 1 hour (Premium+)
- Tested: DR procedures documented and tested quarterly as part of maintenance
RBAC Schema
graph LR
Org["Organizations"]
Members["Members"]
MemberRoles["MemberRoles"]
Roles["Roles"]
RolePerms["RolePermissions"]
Perms["Permissions"]
Settings["OrganizationSettings"]
APIKeys["APIKeys"]
Scopes["Scopes"]
Org --> Members
Members --> MemberRoles
MemberRoles --> Roles
Roles --> RolePerms
RolePerms --> Perms
Org --> Settings
Org --> APIKeys
APIKeys --> Scopes
04Scalability Design
Horizontal Scaling Strategy
| Traffic Tier |
Infrastructure |
Capacity |
| < 2K DAU |
2 API pods (64MB each), 1 DB primary |
Conservative (Launch) |
| 2K-10K DAU |
2-4 API pods, 1 DB primary, Redis |
Base Scenario |
| 10K-50K DAU |
4-8 API pods, 1 primary + 1 read replica |
Aggressive Marketing |
| 50K-100K+ DAU |
8-16 API pods, clustered DB, Redis cluster |
Growth Ready |
Traffic Scenarios: Initial projections indicate ~1,500-2,000 DAU at launch (conservative). With planned aggressive marketing, traffic could scale rapidly to 10K-50K+ DAU. The architecture supports gradual scaling without changes to core design — infrastructure is added incrementally through Kubernetes pod scaling and database replicas.
Performance Targets
| Metric |
Target |
Strategy |
| API Response Time |
< 100ms (p95) |
Redis caching, sqlc optimized queries |
| Page Load (B2C) |
< 2s |
Remix SSR, CDN, code splitting |
| Database Queries |
< 50ms |
Indexed queries, connection pooling |
| Availability |
99.9% |
Multi-AZ, health checks, auto-scaling |
Go Performance Advantage
| Metric |
Node.js/NestJS |
Go + Chi |
| Memory per pod |
~200-300MB |
~30-64MB |
| Cold start |
200-500ms |
10-50ms |
| Concurrent connections |
Event loop limited |
Goroutines (thousands) |
| Estimated infra cost |
Baseline |
40-50% lower |
05Integration Architecture
graph TB
subgraph Platform["Platform"]
API["Go API"]
end
subgraph Notifications["Notifications"]
SMS["SMS - Twilio / Infobip"]
Email["Email - SendGrid / Mailgun"]
end
subgraph Payments["Payments"]
Stripe["Stripe - International"]
Local["Local Provider - Serbia"]
end
subgraph WalletPasses["Wallet Passes"]
Apple["Apple Wallet
PassKit - .pkpass"]
Google["Google Wallet
JWT-based Passes"]
end
subgraph Reports["Reports"]
PDF["PDF Generation"]
CSV["CSV Export"]
end
subgraph Monitoring["Monitoring"]
Pager["PagerDuty / Opsgenie"]
Sentry["Sentry - Error Tracking"]
end
API --> SMS
API --> Email
API --> Stripe
API --> Local
API --> Apple
API --> Google
API --> PDF
API --> CSV
API --> Pager
API --> Sentry
Wallet Pass Integration (Apple & Google)
Server-Side Pass Management
- Apple Wallet (PassKit): Server-side .pkpass generation with certificate signing, push notification updates via APNs, pass template management
- Google Wallet: JWT-based pass creation via Google Wallet API, real-time pass updates, class/object management
- Common: Pass lifecycle management (create, update, expire), event-driven updates via message queue, pass analytics and tracking
graph LR
subgraph Platform["Platform"]
API["Go API"]
WalletSvc["Wallet Pass Service"]
end
subgraph Apple["Apple Wallet"]
PassKit["PassKit
.pkpass Generation"]
APNs["APNs
Push Updates"]
Certs["Apple Certs
Pass Signing"]
end
subgraph Google["Google Wallet"]
GWAPI["Google Wallet API
JWT Passes"]
GWUpdate["Real-time Updates"]
end
API --> WalletSvc
WalletSvc --> PassKit
WalletSvc --> GWAPI
PassKit --> Certs
PassKit --> APNs
GWAPI --> GWUpdate
06Development Phases
Phase 1: MVP (Foundation)
- Core Go API + Database Schema
- B2C Portal (anonymous lookup) - Remix + shadcn/ui
- Basic Admin Panel
- Authentication/Authorization
- Deployment Infrastructure (K8s, CI/CD)
Phase 2: B2B + Payments + Wallet Passes
- B2B Portal with RBAC
- Organization & Team Management
- Payment Integration (Stripe)
- Apple Wallet & Google Wallet Pass Generation (server-side signing, templates, push updates)
- Report Generation (PDF/CSV)
- Notification System (Email/SMS)
Phase 3: Hardening + Compliance
- Security Hardening & Penetration Testing
- Audit System & Compliance Logging
- Monitoring & Alerting (Prometheus, Grafana)
- Disaster Recovery & Backup Strategy
- Performance Tuning (as traffic grows)
Phase 4: Enhancement
- Advanced Analytics
- API Extensions
- Mobile Optimization
- Continuous Improvement
Indicative Timeline
| Phase |
Duration |
Milestone |
| Phase 1 (MVP) |
10-12 weeks |
Core functionality live |
| Phase 2 (Prod) |
10-12 weeks |
Production + Wallet Passes |
| Phase 3 (Harden) |
4-6 weeks |
Security hardened, audit-ready |
| Phase 4 (Enhance) |
Ongoing |
Continuous improvement |
Total to Production: 24-30 weeks (6-7.5 months)
07Cost Estimates
Development Costs
| Phase |
Effort Range |
Description |
| Phase 1 (MVP) |
€42,000 - €58,000 |
Core API, B2C, Basic Admin |
| Phase 2 (Prod) |
€40,000 - €55,000 |
B2B Portal, Payments, Wallet Passes, Reports |
| Phase 3 (Harden) |
€18,000 - €26,000 |
Security Hardening, DR, Audit |
| Phase 4 (Initial) |
€12,000 - €20,000 |
Analytics, Enhancements |
| Total |
€170,000 - €225,000 |
Full platform |
Infrastructure Costs (Monthly)
| Scale |
Cloud Estimate |
Components |
| Launch (~2K DAU) |
€300 - €600/mo |
Minimal K8s, single DB, Redis |
| Base (2K-10K DAU) |
€600 - €1,200/mo |
Scaled pods, monitoring, backups |
| Aggressive (10K-50K DAU) |
€1,200 - €2,500/mo |
DB replicas, Redis cluster, full monitoring |
| Growth (50K+ DAU) |
€2,500 - €5,000/mo |
Full HA setup, clustered DB |
Note: Go backend reduces compute costs by ~40% compared to Node.js at scale
08Maintenance & Support
SLA Tiers
| Level |
Response Time |
Availability |
Monthly Cost |
| Standard |
4h critical / 24h normal |
99.5% |
€2,500 - €3,500 |
| Premium |
1h critical / 8h normal |
99.9% |
€4,500 - €6,000 |
| Enterprise |
30min critical / 4h normal |
99.95% |
€7,500 - €10,000 |
Included in Maintenance
- 24/7 monitoring and incident response
- Security patches and updates
- Database maintenance and optimization
- Backup verification
- Performance tuning
- Monthly reporting
- Up to 20 hours/month feature development (Premium+)
09Compliance & Legal Framework
The platform is designed with privacy-by-design and privacy-by-default principles embedded into the architecture from day one — not retrofitted. All data processing is minimized to what is strictly necessary for platform functionality.
GDPR Alignment (where applicable)
| GDPR Principle |
Implementation |
| Art. 5(1)(c) — Data Minimization |
Device identifiers stored as SHA-256 hashes only; B2C requires zero PII; B2B collects only business-necessary data (company name, business email, role) |
| Art. 5(1)(b) — Purpose Limitation |
Each data field has documented processing purpose; no secondary use without explicit consent; data processing registry maintained |
| Art. 5(1)(e) — Storage Limitation |
Automated data retention policies with configurable TTLs; expired data permanently purged (not soft-deleted); retention schedules documented per data category |
| Art. 5(1)(f) — Integrity & Confidentiality |
AES-256 at rest, TLS 1.3 in transit, field-level encryption for PII, key rotation, access controls, immutable audit trail |
| Art. 5(2) — Accountability |
Complete audit logs, processing records (Art. 30), DPO contact point, data processing agreements (DPA) for sub-processors |
| Art. 15-20 — Data Subject Rights |
Technical capability for data export (Art. 20 portability), data access reports (Art. 15), rectification (Art. 16), and erasure/right to be forgotten (Art. 17) — admin tooling for processing requests |
| Art. 25 — Privacy by Design |
Anonymization (B2C), pseudonymization (hashed identifiers), minimal data collection as architectural defaults — not opt-in features |
| Art. 33-34 — Breach Notification |
Incident detection via monitoring stack, documented response procedure, technical capability to notify within 72h, affected user notification tooling |
Zakon o zaštiti podataka o ličnosti (ZZPL) — Serbian Law Compliance
Serbia's Law on Personal Data Protection (Zakon o zaštiti podataka o ličnosti, "Sl. glasnik RS" br. 87/2018) is closely aligned with GDPR. The platform addresses Serbian-specific requirements:
| Requirement |
Implementation |
| Data Localization |
Hosting options within Serbia or EU; configurable per deployment — data residency can be restricted to Serbian territory if required by regulation or client preference |
| Poverenik (Commissioner) Compliance |
Processing records structured per Poverenik requirements; system supports inspection and audit requests |
| Cross-Border Transfers |
Where data leaves Serbia, appropriate safeguards applied (Standard Contractual Clauses or adequacy decisions); sub-processor registry maintained |
| Serbian Language |
Full Serbian language support for all user-facing portals; consent forms, privacy notices, and terms in Serbian |
| Local Payment Integration |
Support for Serbian payment providers alongside international (Stripe); compliance with NBS (National Bank of Serbia) e-commerce regulations where applicable |
| Consent Management |
Granular consent collection with timestamp and version tracking; easy withdrawal mechanism; consent records exportable for regulatory review |
Auditability
The system is built to be auditable at every level:
- Data Processing Registry: Maintained automatically — records what data is processed, why, by whom, retention period, and legal basis
- Immutable Audit Logs: All critical actions (data access, modifications, admin operations) logged with actor, timestamp, IP, and before/after state
- Access Reports: On-demand generation of "who accessed what data and when" reports for regulatory inquiries
- Consent Trail: Full history of user consents — when granted, what version of terms, when withdrawn
- Incident Log: Security events and incidents tracked with response timeline for breach notification compliance
10Team Composition
| Role |
Allocation |
Responsibility |
| Lead Architect |
100% |
Architecture, Performance, Code Review |
| Full Stack Engineer |
100% |
API, Integrations, Portals |
| Full Stack Engineer |
100% |
API, Integrations, Portals |
| DevOps Engineer |
50% |
Infrastructure, CI/CD, K8s |
| QA Engineer |
50% |
Testing, Automation |
| Project Manager |
25% |
Coordination, Reporting |
Next Steps
- NDA Signing - To receive full specification
- Discovery Workshop - 1-2 days to refine requirements
- Detailed Proposal - Fixed-scope quotation after discovery
- Contract & Kickoff - Project initiation