POSIFY – Parking Management Platform
An integrated parking management platform — Point of Sale, Backoffice, and real hardware, wired together with event-driven microservices.
Full-Stack Developer Intern → Freelance Software Developer
POSIFY is a closed-source, production system built for Asteroidea under an active NDA. The source code isn't public, but this case study covers the architecture, my contributions, and UI screenshots.
Overview
POSIFY is Asteroidea's parking management solution: a Point of Sale (POS) application running at parking terminals, paired with a Backoffice platform for administration, monitoring, and configuration.
I joined as a final-year (PFE) intern to build core backend services and frontend workflows, then continued on a freelance basis after graduating, helping move the platform from internal testing toward real customer demos and deployment.
What I Did
- Designed and implemented REST APIs and backend services in Go (Gin), covering business logic and PostgreSQL data modeling for both POS and Backoffice.
- Built React/TypeScript interfaces delivering day-to-day operational workflows and admin/configuration screens.
- Built event-driven microservices with NATS to keep POS, Backoffice, and external systems in sync in real time.
- Developed a dedicated microservice to integrate EPSON receipt printers, plus hardware integrations for the PMS, tariff engine, barrier, and camera systems via HTTP, Server-Sent Events, and NATS.
- Implemented authentication, role-based access control (RBAC), and admin dashboards.
- Containerized every service with Docker/Docker Compose and shipped images to a private Nexus registry as part of the deployment pipeline.
- As a freelancer, kept shipping features, refactors, and performance improvements, and helped prepare the platform for real customer demos and deployment.
Architecture
The backend is split into Go (Gin) microservices, each owning a slice of the domain — printing, tariffing, access control — communicating asynchronously over NATS instead of tight point-to-point calls, so new hardware or services can be added without reworking what already exists.
PostgreSQL is the system of record for POS/Backoffice data, while real-time events (a barrier opening, a ticket printing) flow over NATS and Server-Sent Events to keep the POS UI and Backoffice dashboards live-updating.
Everything runs containerized with Docker Compose locally and in staging, with images published to a private Nexus registry before being validated in a company testing environment ahead of deployment.
Challenges & How I Solved Them
Talking to real hardware
Parking terminals aren't just software — the POS had to reliably drive an EPSON receipt printer plus a PMS, tariff engine, physical barrier, and camera system, each with its own protocol quirks. I built a dedicated printer microservice and integrated the rest through a mix of HTTP, SSE, and NATS depending on what each device needed.
Keeping two apps and hardware in sync
POS terminals, the Backoffice, and physical hardware all need a consistent view of state in real time. The event-driven NATS architecture meant designing clear event contracts up front so services could evolve independently without silently drifting out of sync.
From intern project to production
The hardest part of the freelance phase hasn't been writing new features — it's been the less visible work: refactoring, performance tuning, and extensive validation in production-like environments so the platform holds up for real customer demos and deployments.
Consistent, Active Development
Asteroidea uses GitLab internally rather than GitHub, so this activity graph is the real day-to-day record of the internship and freelance work — commits, merge requests, and reviews on POSIFY, not a GitHub profile that happens to look quiet during that period.
