Architecture
I've shipped row-level, schema-level, and hybrid isolation. Each comes with trade-offs I've had to work through.
Done it enough times to have opinions.
MULTI-TENANT SaaSI design systems that outlive their vendors_
Software architect based in Istanbul.
A decade of building systems that teams can keep running and make their own.
Cihan Taylan / Software architect↓
I build the boring parts right, so the interesting parts can happen.
I choose tools to fit the problem: open source where possible, managed services where they make sense.
Architecture is a bet on the future. I try to make the kind that ages well.
I work with teams on solutions they can understand, maintain, and build on.
Service boundaries
I help teams decide when to split a monolith into services and when to keep it together.
Split when the boundaries are clear and the team can support them.
MONOLITH → MICROBullMQ · gRPC · Kafka
I build reliable background jobs, bidirectional streams, and event pipelines, with tools chosen for the latency each system needs.
Job queues and event streams solve different problems. I start with what the system needs.
ASYNC & REAL-TIMEModernization
10-year-old PHP still making money? Respect. Let's give it another 10 years without a rewrite.
The best legacy is the code that still runs.
LEGACYEnd-to-end engineering setup
I set up CI/CD, Docker orchestration, automated deployments, observability, and practical monorepo workflows. Open-source tools keep the team in control of its environment.
A good development environment starts paying off on day one.
DEV ENVIRONMENTSAudits
Before an acquisition, funding round, or major investment in development, I review the codebase and make its risks clear.
Every codebase tells the truth if you know how to read it.
TECHNICAL DUE DILIGENCEMy work at SAGENTIQ
I founded SAGENTIQ to help teams put AI to work through consulting and training. It's where I bring this engineering perspective to company-wide challenges.
Explore SAGENTIQOpinions I'll defend at 2am.
Opinions shaped by a decade of architecture decisions. Some are open to debate. Open one to see my reasoning.
You pay in latency, harder debugging, and operational complexity. I keep the monolith until the service boundaries are clear to the team. Splitting too early can cost months without solving the problem you started with.
A managed service can be worth the dependency. I want to understand the costs and the migration path before committing, because both can become harder to manage over time. Being able to change cloud providers matters to me.
Developer experience is an early deliverable. I write the Compose configuration before the application code. How quickly a new teammate can get a working environment says something about the architecture.
An ADR records why a decision was made; a README helps the next person get started. Six months later, I may have forgotten the reasoning. Someone taking over the project needs that context too.
Kafka gives you a durable log that you can replay. I use it for those properties. When the application needs relational queries, I keep those in a database designed for them.
I value decisions that are easy to reverse. Every pattern we add may eventually need to be removed, so I consider that cost while designing the system.
Managed services put the cost on an invoice. Open source puts more of it in the team's engineering time. I count both when comparing options. When autonomy matters, I often find open source worth the effort.
Shared tables with tenant_id are a practical starting point for many SaaS products. Separate schemas or databases come with different isolation and operating costs. I choose based on customer requirements and budget, including compliance and data residency, rather than how the diagram looks.
I want metrics at 10 requests per second, before traffic reaches 10,000. Adding Prometheus and Grafana early helps me understand the system before growth makes problems harder to diagnose.
When a request succeeds, and when it doesn't.
Explore four scenarios: success, rejection, rate limiting, and degraded service. Follow a request to see where time is spent and which decisions shape the response.
An illustrative request flow. Code and timings are examples, not measurements from a live system.
scenario: Success · successful request · 30ms total
// WHY THIS STAGE
Nginx
Edge termination, TLS, connection pooling. First line of defense against flood traffic.
// CODE AT THIS STAGE
# nginx.conf
location /api {
limit_req zone=api burst=20;
proxy_pass http://backend;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Request-ID $request_id;
}// TELEMETRY
observability
›access.log
›upstream.ms
›status_code metric
The tools I work with, and the ones I watch.
The stack behind my web, mobile, desktop and AI work, plus the tools I'm exploring or following. Five rings show how each fits into my work.
Browse technology list
● CORE · default● PROVEN · used in practice● EXPLORING · trying out● WATCHING · following● PAST · no longer using
// updated October 2026 · explore the map or open the list below
From the workbench.
Recurring problems, everyday engineering habits, and how I keep learning. A closer look at the work behind the decisions.
Experience
The same problems, different logos.
Job titles and technologies change. The problems are often familiar. These are the ones I've worked through across a decade of teams.
“Monolith becoming unmaintainable, team shipping slower every quarter.”
4×TIMES
“Zero observability. Every bug a mystery. Every incident a 3am guessing game.”
6×TIMES
“Cloud bill doubled in a year and no one knows why.”
3×TIMES
“New team, no shared dev environment. Onboarding takes two weeks.”
5×TIMES
“Legacy PHP that still makes money. Nobody wants to touch it.”
2×TIMES
“Multi-tenant SaaS, wrong isolation model picked three years ago.”
3×TIMES
“Real-time system stuck on polling, product complaining about lag.”
2×TIMES
“CI/CD that everyone fears. Deploy Fridays forbidden by folklore.”
4×TIMES
// a decade of work · rounded figures · client details kept private
What teams leave with
The shape of a healthy engineering team.
Common starting points, and the working practices I help teams build toward.
// BEFORE
xOnboarding takes two weeks
xDeployments take manual effort. Fridays are off-limits.
xNo observability. Debugging is guesswork.
xCloud bill grows, nobody knows why.
xLocal development fails for half the team.
x"Works on my machine" still passes as an explanation.
→
// AFTER
✓Clone the repo, run one command. Ready within two hours.
✓Git push → production in minutes.
✓Dashboards and traces help the team investigate problems.
✓Costs are visible. Bills are predictable.
✓Local environments stay consistent with production.
✓"Works on my machine" is no longer enough.
How I learn
I learn by building, then asking why.
A working system gives me something to question. These are the habits that help me test what I know and learn from the people I work with.
METHOD
I build boilerplates to learn stacks.
To learn a technology deeply, I build a starter with authentication, queues, CI/CD, Docker, and tests. Using it in three real projects tells me far more than a tutorial can.
METHOD
I test how systems fail.
I deliberately test failures in staging. Incidents in production also reveal assumptions nobody wrote down, and give us something concrete to learn from.
// lessons from incidents feed into architecture decision records
METHOD
I build to understand what I'm buying.
If a tool costs $500/month, I want to know why. Usually I can build 80% of it in a weekend. The remaining 20% teaches me whether to buy or keep building.
// self-hosted PaaS replacing $6k/mo SaaS
METHOD
I pair with AI when I'm stuck.
I use AI to explore ideas and challenge my assumptions. Explaining a problem to a model often exposes the part I haven't understood yet. Its answers still need checking.
// Claude and Codex in my daily work
METHOD
I teach what I just learned.
Explaining something to another person shows me where my understanding stops. I work through real examples with teams, using whiteboards, pairing, and plenty of questions.
// hands-on mentoring inside teams
// A DECADE IN NUMBERS
6
boilerplates built
12+
production systems with failures
4
tools rebuilt from scratch
8
engineers mentored
0
blog posts written
› working code is how I put what I learn to the test.
Building gives me experience.
Taking time to question my decisions helps me use it.
I try to leave room for both.
The engineer is not the whole person.
What I do away from the keyboard. Though I still catch myself thinking about how things work.
Music
Guitar. Riffs, rhythm, the patience to practice a phrase until it's clean. Same muscles as clean code.
Two wheels
Motorcycles taught me risk management before any incident postmortem did. Speed only matters when you trust the brakes.
The lens
A photographer's eye is a product manager's eye: framing, hierarchy, what you leave out of the frame.
Let's think it through.
Working through an architecture decision, untangling a system, or exploring an idea? Tell me what you're working on.
cihantaylan@cihantaylan.comI read every message. A little context helps us start a useful conversation.