B. Bayrkdar Get in touch

Software Engineer

Web platforms
Application engineering
Realtime systems
Product engineering

Software that
stays connected.

I'm B. Bayrkdar. I engineer production software: web platforms, application backends and realtime systems. I turn complex product and domain problems into applications that stay maintainable.

Scroll

Four years building and shipping production software across web applications, realtime systems, platform tooling and interactive products. I work across the frontend and backend, and I care most about how a system behaves when something goes wrong.

Engineering snapshot

Six areas I work in professionally. Pick one to see what it involves.

WebSocket platforms with a session lifecycle, reconnect semantics, fan-out and role-based access, built to be observable in production.

Node.js · Fastify · WebSockets · JWT/RBAC · Prometheus

Realtime platform case

Selected engineering

Production systems first: a realtime platform, device operations tooling, cross-platform device software and the applications built for real businesses. Experiments are kept separately, in the lab.

Realtime Platform Systems Architecture & Engineering

RTMS

A realtime messaging & management platform

Digital media installations have to talk to web apps, mobile apps and backend services: reliably, securely and without a one-off integration for every installation.

I designed and built RTMS as the layer between them. Its central idea is that the session, not the socket, is the unit of work. Connections drop and come back, but a session keeps its members, its policy and its audit trail.

Node.js Fastify WebSockets REST JWT RBAC Docker

  • ConstraintLong-lived connections over networks that drop without warning.
  • ConstraintMany tenants on one platform, strictly isolated from each other.
  • ConstraintEvery message traceable when something goes wrong in production.

System model

Select a component to see what it is responsible for.

Clients
Edge
Core
Operations

Session manager Owns the session lifecycle: create, join, resume, leave, expire. Membership outlives individual connections.

Session lifecycle

Sequence diagram between Client, RTMS, Installation and Audit log for the selected lifecycle stage.

  • Session first, connection second

    Reconnects resume an existing session instead of creating a new one, so a dropped network link never orphans an installation.

  • Validate at the boundary

    Every REST body and WebSocket message is checked against a schema before it reaches business logic, so malformed input fails early and predictably.

  • Backpressure at the edge

    The WebSocket pipeline handles reconnection and backpressure, so one slow consumer can't stall everyone else.

  • Security proven by failing tests

    JWT authentication, role-based access and tenant isolation, with negative tests that deliberately try to cross every boundary.

  • Observable from day one

    Structured Pino logs, Prometheus metrics and Grafana dashboards, with correlation IDs that follow each message from end to end.

  • Same container everywhere

    The platform ships as a Docker image, so local, test and production environments run the same build.

Verified results

  • p95 latencyMeasured p95 latency within its target.
  • Zero ghost sessionsDisconnect, reconnect and expiry scenarios leave no orphaned sessions behind.
  • Negative security testsAttempts to cross authentication, role and tenant boundaries are tested and rejected.
  • Unit + E2EAutomated unit and end-to-end test suites.

Device Operations Platform Tooling & Deployment

Device operations

Finding, configuring and deploying to devices in the field

When software runs on many devices in many places, the hard part is operations: knowing what's out there, what state it's in, and changing it safely.

I worked on the operational tooling behind that: the interfaces and APIs that take an operator from finding a device to verifying a deployment. They're built to stay understandable when an operation is slow, only partly succeeds, or fails.

Vue Nuxt TypeScript Fastify Laravel / PHP Docker CI/CD

Operator flow

Step through the workflow the tooling supports.

The operator

The system has to

  • Reusable interface architecture: shared Vue and Nuxt building blocks across operational screens, typed end to end with TypeScript.
  • Designed for partial failure: clear states and error handling for operations that take time, or don't finish.
  • Across the stack: APIs in Fastify and Laravel, with logging for operations that run unattended.
  • Repeatable releases: Docker images and CI/CD pipelines, so a release is a routine step, not an event.

Device Software Cross-platform Architecture

Smart Display Player

One player, three TV operating systems

Signage screens run unattended for months on hardware from different vendors. Forking the player per platform would multiply every bug fix by three.

The player core (scheduling, playlists, rendering, diagnostics) is written once. Everything that differs between platforms lives behind a single adapter contract.

Tizen webOS Android TV Remote diagnostics OTA

Platform adapter

Shared player core Scheduler Playlist Renderer Diagnostics

ContractTizenAdapter

Switching targets swaps one module. The core and the contract stay the same. Native calls are simplified.

Application engineering

Production applications across very different domains. I worked on each as part of a team, so these describe the engineering problems I worked on, not whole products.

Across these: PHP · Laravel · Blade · Vue · TypeScript · REST APIs · Progressive Web Apps

A shared application foundation reused across products: accounts and authentication, navigation, security, data integrations and common components. New products start from a consistent, tested structure, so feature work goes into the domain instead of re-solving the same infrastructure.

Reusable foundations · Auth & accounts · Standardised structure · Shared components · Integrations

Operational data from production lines, organised as a hierarchy: location, line, machine, task. KPIs, measurements and statistics have to stay readable at every level, so the interface is built around drill-down navigation and dashboards rather than tables of numbers.

    Illustrative data. Select a row to drill down.

    Hierarchical information architecture · KPIs & measurements · Data visualisation · Operational dashboards

    Complex domain calculations that used to be done by hand, turned into a guided multi-step workflow. The software validates input at every step, applies the business rules, handles user roles and permissions, and generates the resulting output.

    Multi-step configuration · Business logic · Input validation · Roles & permissions · Generated output

    An installable web app that behaves like a native one: user accounts and persistent sessions, digital playcards and balances, promotions, multiple locations and languages, and content managed through a CMS.

    Installable PWA · Persistent sessions · Mobile-first UX · Multi-language · CMS-driven content

    Travellers buy tickets and passes in an app and board with a QR code. Kiosks on board cover people without the app, staff have their own interface, and a back office manages schedules, sales and service announcements.

    QR ticketing · Role-based staff tools · Back office · Schedules · Push notifications

    A mobile service for people who can no longer drive themselves. It covers onboarding with identity verification, ride matching, live tracking of the driver's arrival, and automatic payment.

    Verification flows · Matching · Live tracking · Payments

    What I bring

    Organised by engineering responsibility, with the tools I use for each in production.

    Engineering lab

    Experiments and explorations, kept apart from production work. This is where I practise algorithms, performance and graphics.

    Experiment C++ / SDL3

    Particle engine

    Spatial partitioning and allocation-free hot loops

    Comparing every particle against every other takes n² checks: 12.5 million pairs per frame at 5,000 particles, far more than fits in a 16 ms frame.

    A quadtree rebuilt every frame narrows each particle's search to its neighbourhood, and object pooling keeps allocation out of the hot loop. Below is a JavaScript port: compare both strategies, switch on elastic collisions, and light the particles with a moving point light.

    Collision & light

    Broad phase
    On contact
    Shading

    Checks per frame
    —
    Compared with brute force
    —
    Broad-phase time
    —
    Contacts per frame
    —

    Elastic bounce exchanges momentum along each contact normal, and walls reflect particles back in. With point light shading, move your pointer over the canvas to move the light.

    This site's WebGL stage
    One Three.js scene for the whole page: a refractive crystal, instanced message packets and a 9,000-particle field that a vertex shader morphs between sections. It pauses when the tab is hidden and shows still frames for reduced motion.
    Engines & tooling
    Engine and tooling experiments in C++ and Unity, focused on frame budgets, spatial data structures and design patterns that keep engine code maintainable.

    Design for clarity.

    Diagrams, demos and measurable outcomes. An architecture should make sense to the engineer building it and to the people who depend on it, in the same meeting.

    Build for change.

    Adapters, boundaries and reusable foundations, so platforms and products can each change on their own schedule without forcing rewrites.

    Prove the work.

    Tests that try to break things, metrics that show how the system behaves in production, and decisions written down. Evidence over screenshots.

    Hiring a software engineer, or planning a platform that has to stay up?

    Let's build something that stays connected.

    [email protected]