Enyakininda
01 — The brief
Enyakininda is a location-based services marketplace for Turkey. A consumer searches for a category — a plumber, a vet, a barber — and sees the nearest verified businesses first, compares them by rating and distance, and contacts or books them. Businesses pay for listings and subscriptions to be found. The product serves three audiences at once: customers, vendors, and an admin and operations team.
Three constraints shaped every decision. ‘Nearest’ had to be genuinely accurate, not approximate. Payments had to be secure and subscription-aware, with trials, renewals and invoices. And the whole system had to respect Turkish data-privacy law (KVKK) from the very first table onward.
02 — Approach
The backend is a modular monolith built with Spring Modulith: 23 feature modules — vendor, payment, review, search, notification, moderation and more — inside a single deployable. Modules talk to each other through application events published after the transaction commits and handled asynchronously, so a new review or a completed payment fans out to search, analytics and notifications without wiring the callers directly together.
‘Nearest’ is answered in the database. Vendor locations live in PostgreSQL with PostGIS, and proximity is a spatial query — ST_DWithin and ST_Distance over a geography column — rather than a call out to an external routing API. The closest result comes from a spatial index, not a per-request round-trip to someone else’s service; Google Maps is used only to draw it. Payments run through Iyzico, and authentication is delegated to Supabase, whose JWTs the backend validates as an OAuth2 resource server.
- Proximity PostGIS spatial queries — ST_DWithin / ST_Distance
- Payments Iyzico subscriptions — trials, installments, 3-D Secure, PDF invoices
- Auth Supabase-issued JWT, validated as an OAuth2 resource server
- Media Cloudflare R2 + a server-side WebP pipeline (five sizes)
- Messaging Resend email · Firebase Cloud Messaging push
- Clients React 19 PWA · admin panel · React Native (Expo) app
None of this was free. Each choice bought something and charged for it somewhere else — the work was in choosing where to pay.
-
Trade-off 01
Modular monolith over microservices
One deployable with enforced module boundaries (Spring Modulith) keeps a small team fast and the system easy to reason about. The cost is discipline: boundaries have to be defended in review — which is exactly why the codebase carries its own architecture audit that scores module compliance and flags cross-module leakage.
-
Trade-off 02
PostGIS proximity over a routing API
Answering ‘nearest’ from a spatial index means no per-request latency, no external quota and no third-party cost on the hottest query in the product. The cost is that geo-distance is straight-line by default, so anything needing true road distance becomes a deliberate, separate addition rather than a freebie.
-
Trade-off 03
Events after commit over direct calls
Publishing application events after the transaction commits, handled on async executors, decouples modules and keeps the write path short. The cost is eventual consistency: downstream effects land a beat later, and tracing a flow means following events rather than a single call stack.
-
Trade-off 04
Cloudflare + Supabase over a full AWS stack
Managed edge, storage and Postgres cut egress cost and operational surface for a solo-run product, and the migration was done before launch to avoid moving live users. The cost is tighter coupling to those platforms and less low-level control than raw infrastructure would give.
The closest result should come from an index — not a round-trip to someone else’s API.
03 — Results
Enyakininda is live — on the web at enyakininda.com and as a native iOS and Android app on the stores — all served from one Spring Boot backend. The platform runs 23 feature modules, roughly a hundred domain entities and over two hundred API endpoints, with proximity search, subscription payments and a full moderation and analytics pipeline in production.
04 — What’s next
The groundwork — Prometheus metrics, structured audit trails, scheduled analytics — is already in place. Next is deepening observability, growing the vendor side, and pushing the busier flows further toward event-driven, near-real-time behaviour.