Dimitar "Mitko" Zlatev · Inner Circle · Mar 2022 – Aug 2026

Four Years in the Monolith

A record of what shipped and what it moved — assembled from GitHub history across the theinnercircle org and from Slack (#engineering, #back-end-team, #important-stuff, #pixintegration, #product). Every figure below carries its source.

The brief can you check Slack - mainly engineering and backend channels and theic repo history and compile a list of feature that I've been working on and figure out some achievements/impact that my work had on the company - increased revenue, performance, etc.?
1,462merged PRs
14repositories
7,086commits in theic
#1contributor
4.5years, continuous
Section 01

Standing in the codebase

Two years of commits to theic master, as GitHub counts them.

GitHub contributors page for theic, last 24 months: zlatevbg ranked number 1 with 2,347 commits, michick number 2 with 1,604, vftochogianni number 3 with 1,216, phgeorgiev number 4 with 865, opojal number 5 with 846, cattz number 6 with 292, each with a weekly contribution histogram.
GitHub's own ranking, 10 Aug 2024 – 16 Aug 2026. That's sustained delivery rather than a couple of big pushes. github.com/theinnercircle/theic/graphs/contributors?from=8/10/2024
Section 02

Measured impact

Only outcomes with a number attached and a traceable source. Everything else lives in the chronology below.

-30%

Brazilian payment processing cost

Led the backend integration of PagBrasil / automated Pix — API client, webhooks, consent flow, payment links, recurring charges, refunds, subscription cancellation, micropayments. Brazil is the company's largest market (first €1M revenue month in Aug 2023; 79% of that month's growth).

#important-stuff, demo update, 2026-02-13
4.5M

Accounts purged, ~50 GB reclaimed

Owned the DB Cleanup initiative end to end (Aug 2025 – Jan 2026): 587k already-deleted, 2.7M inactive non-approved and 1.23M inactive approved accounts, plus ~428M related rows, ~22.7M photos and 36 redundant indexes removed.

#engineering 2025-09-16 · #back-end-team 2026-01-12
3.2 → 2.2 ms

Average MySQL latency

Direct consequence of the cleanup and index work, measured twice: 3.2 → 2.9 ms in Oct 2025, and a consistent 3+ ms → 2.2 ms by Feb 2026 — at a sustained 381,321 transactions per minute on the zf-backend service. At that throughput, a millisecond is not a rounding error.

#back-end-team 2025-10-16 and 2026-02-09 (APM)
130 ms

Average OpenSearch query

The search platform you built from zero answers the average query in 130 ms, against MySQL queries it replaced that ran into the seconds. Delivered in three one-month phases — Foundation, Nearby widget, Wall/Matcher — each completed on schedule.

Q4 2024 company update deck, 2024-11-25
2B rows

Likes index, kept in sync

Full sync of ~1M searchable users in ~10 min, ~750K profile-field sets in ~5 min, ~460K lifestyle sets in ~7 min, and the ~2B-row likes subset (of a ~16B-row table) in ~1 week. Incremental sync keeps up with 500–5k modified users/min in under 5 s and 1–10k modified likes/min in under 10 s.

Q4 2024 company update deck, 2024-11-25
-50%

Likes screen load time

GET /likes went from a 383 ms one-month average to ~190 ms after a week of targeted backend fixes. One of the most-hit screens in the app.

#engineering 2025-09-23
-300 ms

Wall endpoint

Removed a stale manually-forced index on the online-users query (PR #2813). Separately, found and fixed a missing cache on superlikes that had been costing ~200 ms on every request since launch.

PR #2813, 2024-03 · ClickUp 861n64yhd, 2023-11
-11–16%

Messages endpoint

GET /messages from 176 ms to 156 ms on quick fixes alone, with a deeper optimisation path scoped but deliberately not taken.

#engineering 2025-10-22
70.75%

Record registration rate

Company high, hit the Sunday after the new registration flow landed. You built its entire backend: /register, registration-state and config endpoints, photo ordering, email verification.

#important-stuff 2026-02-27 — company-level metric
>60s → instant

Admin invite-code search

Marketing couldn't use it. Fixed the query, split the Admin Panel onto separate read/write MySQL connections, and eliminated a recurring class of Sentry deadlocks in the process.

#back-end-team 2026-01-12
Section 03

Evidence on file

Three slides from the Q4 2024 all-hands deck (Week start, 25 Nov 2024) — useful because the framing isn't yours, it's how the project was reported to the whole company — plus the endpoint response times you measured and posted in #engineering.

Slide: High-Level Overview of OpenSearch — what it is, why we use it, how it works, and how the database is kept in sync.
What it is and why. Geographic queries for the Nearby widget and text search over lifestyles were the two use cases MySQL handled badly. The sync design is split in two: periodic for users, likes, profile fields and lifestyles; real-time for newly approved users, deletions, and users flipping in and out of searchable.
Slide: OpenSearch Project Overview — current status, performance learnings, and the five planned phases.
The numbers slide. 130 ms average search query. Full re-syncs: ~1M searchable users in ~10 min, ~750K profile-field sets in ~5 min, ~460K lifestyle sets in ~7 min, ~2B likes in ~1 week. Incremental: 500–5k modified users/min under 5 s, 1–10k modified likes/min under 10 s. Phases 1–3 (Foundation, Nearby, Wall/Matcher) all delivered in their one-month slots.
Slide: OpenSearch Project Overview — challenges, with two annotated response-time charts showing the drop after the user_search table and Nearby widget changes.
The proof chart. Response time sitting in a 500–600 ms band, then stepping down twice — at Use user_search table and again at Nearby Widget — to a 250–300 ms band and staying there. The lower graph marks Enable OpenSearch and the infra spike that followed. This is the single best visual evidence in the whole record.
APM screenshot: GET /likes average latency drops from a 350–450 ms band to about 190 ms in mid-September 2025, while throughput stays flat at 400–600 tpm.
GET /likes — the clean one. Latency sits in a 350–450 ms band through late August and early September 2025, then steps down around the 16th to ~190 ms and stays there. The panel beside it is the control: throughput holds flat at 400–600 tpm straight through the step, so the improvement is the fix, not a drop in traffic. Say that out loud whenever you show this — it's the difference between a claim and a proof. #engineering, 2025-09-23
APM screenshot: GET /messages average latency around 134–180 ms over 30 days, with a span-type breakdown showing MySQL at 58 percent of time spent.
GET /messages — the smaller win, and the reason it was smaller. Latency drifts from ~180 ms down to ~134 ms after the 15 October release. The third panel is the interesting one: 58% of the time is MySQL, 40% app, 2.1% HTTP — which is exactly why quick app-side fixes only bought 11–16% here, and why the remaining headroom was documented rather than chased. Knowing when to stop is worth as much as the fix. #engineering, 2025-10-22
APM screenshot: mysql/theic dependency overview showing 2.2 ms average latency and 381,321.9 transactions per minute from the zf-backend service.
mysql/theic after the cleanup. Average latency holding at 2.2 ms across January–February 2026, against 381,321.9 tpm from zf-backend and a failed-transaction rate with no data to display. This is the slide for anyone who thinks a millisecond doesn't matter: at this throughput, the ~1 ms the cleanup took out is roughly six minutes of database time saved every minute of wall clock. #back-end-team, 2026-02-09

The same two endpoints, side by side

Average response time, production. Figures as stated in your #engineering posts of 2025-09-23 and 2025-10-22.

Before After
0 100 200 300 400 ms GET /likes GET /likes — before: 383 ms GET /likes — after: 190 ms 383 ms 190 ms -50% GET /messages GET /messages — before: 176 ms GET /messages — after: 156 ms 176 ms 156 ms -11%
The averages from the two posts above, on one scale — for the version of this you paste into a document where the APM screenshots are too wide to read.
Section 04

The chronology

Grouped by year because the arc matters: growth plumbing → monetisation experiments → search platform → cleanup and modernisation → payments and service extraction.

2022303 PRs

Growth plumbing and the Boost economy

Phone / SMS sign-up

Built and rolled out phone sign-up from a Brazil pilot (50 users) to global release — country gating, daily limits, brute-force detection, Danish number support, login-with-phone when the sign-up cap is hit.

Boost monetisation

Boost Bundles, Boost triggers and logging, shadow-boost A/B test, visibility improvements, city-by-city rollout (Bogotá, Santiago, Belo Horizonte, Brazil), regional price adjustments and discounts, GA event reporting, admin stop-button and filters.

Performance foundations

Wall caching, combined online/offline queries, static Memcached, user-by-PK caching, and moving frequently-modified user fields into Redis with a sync-back job — a multi-attempt project that cut write pressure on the users table.

Event pipeline

Dispatching SNS events from the monolith, ramped 1% → 100% behind a percentage gate, with schema work and a PHP 8 rewrite of the event builder.

2023400 PRs

Monetisation experiments at scale, and the invite flow

Invite flow

End-to-end: invite codes, static code generation for existing users, the invite webpage, send-invite screen, code-grants-free-membership, custom App Store product pages for invited members, tracking, and retirement of the old app/web code paths.

A/B testing platform

Effectively became the owner of the experiments framework — new filter categories, participation visibility in the Admin Panel, support for enrolling existing users, plan handling, and systematic cleanup of expired experiments.

Pricing & packaging tests

Weekly subscriptions (BR, AR, MX, NL, AMS), iOS price increases, Android price decreases, Colombia and Argentina adjustments, Paid-Only App (its own multi-month project: plans, paywalls, permissions, discover, profile and membership slides), Limited Time Offers for less-active users.

Product features

Open Messages, Photo Prompts, Interactable Profile Fields, Lifestyle details, Five Tabs, Liked You / You Liked lists, combined Matches & Messages, Invisible + Protected mode, unblurring one like, Superlikes.

Incident response

Stopped a live phone-sign-up registration attack — killed active sessions, added brute-force detection, and staged the safe re-enable of phone sign-up country by country.

Worth noting: the Boost integrated campaign that Marketing reported as +14% boosts purchased and +10% boost revenue (Oct 2023) ran entirely on the Boost and automated-alert machinery built in 2022–23.
2024345 PRs

The OpenSearch migration

Search platform, built from zero

The dominant project of the year and largely yours: the OpenSearch PHP client, the SearchSync service, sync commands for users, likes, lifestyles, deleted users and orphaned likes, retriable sync jobs, geo-point mapping, Sentry instrumentation, and a documented runbook. Two sync regimes — periodic for users, likes, profile fields and lifestyles; real-time for newly approved, deleted, and users flipping searchable/unsearchable.

Widget-by-widget cutover

Online → Nearby → New wall widgets, then match recommendations, migrated off MySQL one at a time behind admin-only and percentage gates, with rollbacks when a step misbehaved. By the Q4 update, OpenSearch was serving all wall widgets and match recommendations.

Shipped to a plan, and to the company OKR

Phase 1 Foundation, Phase 2 Nearby widget and Phase 3 Wall/Matcher each landed in their one-month slot; Phase 4 (profile fields, lifestyles) followed. "Finish the OpenSearch technical foundation" was a named key initiative under the company's Q4 Lifestyles objective — the widget rework and lifestyle features the quarter was built around all depended on it landing.

The hard parts

Two challenges called out publicly: indexing the ~2B relevant rows out of a ~16B-row likes table, and absorbing the traffic shape change after app v5.10. The peak-load work under the latter fed straight into the 2025 reliability fixes.

CRM & screening

New email template system, platform filters for push and email, CRM triggers for registration, new user categories, the internal screening service and its admin dashboard, manual-screening countries, photo hashing and duplicate detection.

Platform work

SNS events moved to RabbitMQ, DataTap and savelike moved to background jobs, Symfony Cache introduced, the config object wrapper, Rector-driven PHP 7.3 → 8.3 typing, Amplitude deprecated.

2025258 PRs

Cleanup, observability, and Lifestyle Networks

DB Cleanup initiative

Started 1 Aug 2025, closed Jan 2026. See Section 01 — this is the single largest measurable infrastructure win in the record.

Lifestyle Networks / Circles

Backend for the whole feature: network model and statuses, invite codes, banners, network wall, deeplink endpoint, CRM categories, translations, and the Lifestyle Sentences rollout city by city.

Search reliability

When OpenSearch started dropping requests at peak, added a circuit breaker, fallback distance queries, removed fuzziness, capped fallback ranges, and cut the query load — after diagnosing that users hitting the grey error screen were queue-drop victims.

Observability migration

Replaced Bugsnag with Sentry across the monolith, removed New Relic, moved to Monolog, added Elastic APM. Then used it: the Likes and Messages endpoint wins in Section 01 both came out of Sentry data.

Modern API surface

/register, registration state, config endpoint, photo delete/replace, webhooks client and server, Android payment instalments.

2026166 PRs

Payments, and pulling the monolith apart

PagBrasil / Pix

Roughly 25 PRs from API client to full production release — webhooks, consent handling, pending/rejected charge states, duplicate-transaction prevention, refunds, cancel-on-delete, discounted renewals, micropayments. Also the one who caught the Android instalment mispricing bug (1,775 users on 3-month plans, 617 on 6-month) and escalated it.

Event-driven architecture

Outbox pattern and migration, event-schema codegen, RabbitMQ produce and consume in the monolith, SNS/SQS bus decommissioned, background jobs refactored, queues moved to Redis Cluster.

Date feature & Daily Picks

Daily Picks (backend + OpenSearch scoring), Date Coin consumable, buy-screen, home-screen section, feature toggle, admin granting, and the pairing algorithm RFC for Date at Eight.

GraphQL & service extraction

Schema design for members and restrictions, real resolvers behind the API gateway, session validation — the work that lets the mobile apps stop talking to ZF1 directly.

Dev platform

FrankenPHP + Octane, the local Docker topology for the Kotlin services, consolidated dev stack, backend API testing script, per-environment .env, Composer security audit.

Section 05

What you own

Areas where the history shows sustained ownership rather than a single contribution — the useful framing for a review or a promotion case.

AreaSpanEvidence
Monetisation & payments2022 – 2026Boost economy → pricing experiments → Paid-Only App → Android instalments → PagBrasil/Pix → Date Coin
Search platform2024 – 2026OpenSearch client, sync layer, every widget cutover, reliability work, Daily Picks scoring
Database health2024 – 2026Cleanup initiative, index removal, slow-query work, read/write splitting, latency tracking
A/B testing & CRM segmentation2022 – 2026Experiments framework, user categories, IAA/push/email filters, NAM-delay targeting
Registration & auth2022 – 2026Phone sign-up, attack response, email verification, the v5 registration flow backend
Observability2024 – 2026Bugsnag → Sentry, New Relic removal, Monolog, Elastic APM, and using the data to find wins
Admin Panel2023 – 2026Filament migration support, MFA, seeders, ACL and role scoping, performance fixes
Modernisation2023 – 2026PHP 7.1 → 8.3, Symfony Cache, RabbitMQ, outbox, FrankenPHP, GraphQL gateway, service extraction
Section 06

How to use these numbers