Computer engineer · Backend & distributed systems
Arif Emre AbduşoğluI build systems that holdtogether under real load.
Most of my work happens on the side of software nobody sees: transaction boundaries, delivery guarantees, and the seams where one service ends and the next begins. The case study below is the honest, measured version of one such system.
- Based in
- Türkiye
- Focus
- Java · Spring · Kafka · Next.js
- Status
- Open to opportunities
- 13services
- 70,869lines of backend
- 55,022lines of frontend
- 1,524automated tests
Profile
What I actually do
I am a computer engineer who works end to end: domain modelling and backend architecture first, then the interface that has to make it feel simple. I care most about the parts of a system that decide whether it survives a bad day: what happens when a message is delivered twice, when a dependency is down, when two writers race.
Over the past months I took a working modular monolith and turned it into a fleet of thirteen independent services without breaking it: physical database-per-service, a transactional outbox, idempotent consumers, and every cross-service read replaced by a locally owned projection fed from the event log. The frozen monolith stayed byte-for-byte untouched throughout, as a reference and a rollback path.
I write down the reasoning next to the code. Every architectural rule in that platform is enforced by something that fails the build rather than by a convention people are asked to remember, and the documentation that describes the async API is itself a test.
- Role
- Computer engineer · full-stack, backend-leaning
- Primary stack
- Java 21 · Spring Boot · PostgreSQL · Kafka
- Also works with
- TypeScript · Next.js · Python · Go
- Interests
- Distributed consistency · developer tooling · applied LLMs
- Languages
- Turkish · English
Flagship project
App in Handy
A trust platform where value lives on the match, not on the app.
An app is never good in the abstract. It is good at solving a particular problem for a particular person. App in Handy is built around that idea: the unit of value is the Match between a problem and an app, and that is what carries the score.
That product idea is why the system is interesting to build. Scores, demand signals, moderation, search and an AI assistant all read the same content from different angles, which is exactly the situation where a single shared database quietly becomes the thing everyone is afraid to touch. So it is not one service but thirteen, each owning its own data, coordinating through an event log.
13
services
26
event topics
1,524
backend tests
106
schema migrations
Three repositories, three lifecycles
- platform13 services, an edge gateway and 9 shared librariesJava 21 · Spring Boot 3.5 · PostgreSQL · Kafka
- web-uiThe product interface: server-rendered, four localesNext.js 16 · React 19 · RSC-first · 4-tier data layer
- landingThe public marketing surface, deployed on its ownNext.js 16 · OpenNext → Cloudflare Workers
Other side projects
Things I built before this one
Smaller, mostly LLM-shaped, and each of them taught me something that ended up in the platform above. Open one for the summary, or go to its page for the full story.
AI-Powered Content GeneratorLiveA Chrome extension that turns any page into raw material.
A browser extension that reads the page you are on and generates original content from it: product copy, a blog draft, a social post. Two things make it more than a wrapper: a dual-mode scraper that falls back to client-side extraction when a server-side request is blocked, and an evaluation platform that compares AI architectures using a second model as an impartial judge.
- Python
- Flask
- RAG
- PostgreSQL
- Vanilla JS
- Chrome Extension
LLM Proposal Management SystemCompletedReading old proposals to write new ones.
Built during a professional internship. The system ingests a company’s existing proposal documents, works out the structure hiding inside them, and turns that structure into a reusable template, then drafts new proposals into it with retrieval-augmented generation, so the output sounds like the company rather than like a language model.
- Python
- Flask
- Next.js
- React Query
- PostgreSQL
- Alembic
- RAG
- JWT
LLM Remote AssistantIn developmentNatural language in, sandboxed Python out.
An experiment in giving a language model real hands. Instead of a fixed catalogue of commands, the model writes Python for the request at hand and a three-layer safety architecture decides whether that code is allowed to run. A mobile client is the command surface; a lightweight agent on the machine does the work.
- Python
- Flutter
- Go
- Rust
- WebSocket
- Sandboxing
- LLM
Site-ChatIn developmentA conversation layer for any URL.
A real-time chat platform that attaches rooms to web addresses. For individuals it is a place to discuss any page (an article, a product, a video) with the people also reading it. For businesses it is an embeddable widget that puts the same conversation on their own site.
- Go
- Next.js
- TypeScript
- WebSocket
- PostgreSQL
- JWT
Stack
What I work with
Everything listed here is used in shipped code in one of the repositories above. This is an inventory, not a wish list.
Languages
- Java 21
- TypeScript
- Python
- Go
- Rust
- SQL
Backend & data
- Spring Boot 3.5
- Spring Cloud Gateway
- Hibernate / JPA
- Flyway
- Maven
- Kafka / Redpanda
- PostgreSQL
- Redis
- Resilience4j
- MapStruct
Frontend
- Next.js 16
- React 19
- React Compiler
- Tailwind v4
- Zod
- TanStack Query
- Zustand
- Radix UI
Applied AI
- RAG
- pgvector
- BGE-M3 embeddings
- Structured outputs
- LLM-as-a-Judge
- Anthropic
- Groq
Platform & tooling
- Docker
- Docker Compose
- Testcontainers
- Toxiproxy
- OpenTelemetry
- Prometheus
- Grafana
- GitHub Actions
- Cloudflare Workers
Contact
If any of this is useful to you, I would like to hear about it.
I am open to backend, platform and full-stack roles, and to conversations that do not have a job attached to them yet.