Swiss German University
Tangerang, Indonesia2022 - 2026
Bachelor of Information Technology
CompletedSpecializing in Technopreneurship
GPA 3.82 / 4.00
I'm pursuing a unique path that blends technology with entrepreneurship. My studies focus on building technical expertise while developing the business acumen to turn innovative ideas into real-world solutions.
Beyond academics, I actively participate in campus organizations where I've developed leadership skills, creative direction, and event management experience.
Software DevelopmentSystem ArchitectureBusiness ModelingMarket AnalysisEntrepreneurshipProblem Solving
Campus LifeCampus Activities
Secretary
Badminton Club
Member
IT Student Association
Event Division
Chess Club
Head of Creative
Bible Fellowship
Undergraduate Thesis
Load Testing & SRE for a German Logistics Platform
commsult AGResearched at commsult APAC
Ontego Traces, a logistics platform used by German delivery operators, ran in production with no performance baseline and no way to detect service degradation under load. My thesis built an SRE-aligned benchmarking framework and ran ten controlled experiments against its highest-volume write path — to find where it actually breaks, and prove which fixes matter.
Site Reliability EngineeringLoad Testing (k6)Docker SwarmAutoscalingObservabilityContinuous Delivery
+0%
Throughput gained
from database tuning on a single replica
−0%
Tail latency cut
p95 on one tuned replica vs the baseline
0
Controlled experiments
each isolating one infrastructure variable
0
SRE golden signals
latency, traffic, errors & saturation — live on Grafana
Ten experiments, one verdict
Each bar is a real k6 run under identical load, shown relative to the untuned baseline. The tuned single replica wins both metrics — beating the two-replica configurations it was supposed to lose to.
Relative throughput
Longer is betterDB tuned 1 replica · pool 10Best
Pool sweet spot 2 replicas · pool 4
DB tuned + scale 2 replicas · pool 10
Conn. proxy (1R) 1 replica · pool 20
+1 replica 2 replicas · pool 5
Conn. proxy (2R) 2 replicas · pool 20
Baseline 1 replica · pool 5Baseline
Relative tail latency
Shorter is betterDB tuned 1 replica · pool 10Best
Pool sweet spot 2 replicas · pool 4
+1 replica 2 replicas · pool 5
Conn. proxy (1R) 1 replica · pool 20
Conn. proxy (2R) 2 replicas · pool 20
DB tuned + scale 2 replicas · pool 10
Baseline 1 replica · pool 5Baseline
The instinct is to scale out. But tuning the database on one replica delivered more throughput and lower latency than adding a second — because the real bottleneck was never CPU.
Scale out · 2 replicas
+0%
throughput vs baseline — latency improved, but throughput barely moved
Tune the DB · 1 replica
+0%
throughput vs baseline — and the lowest tail latency of any run
The ceiling I found
A live pg_stat_activity trace revealed the hard limit: every write request contends for the same shared configuration row, serialising all concurrent writes. It's the last rung of the bottleneck ladder — an application-level fix, not an infrastructure one.
CPU bound
Add service replicas
Queue bound
Scale the message consumers
Database bound
Tune commit, cache & pool
Hot-row bound
Fix the application code
What I learned
Measure before you scale
Adding a second replica improved tail latency but lifted throughput by under 10%. Horizontal scaling only pays off when CPU is the constraint — and here it wasn't.
The database is the ceiling
Disabling synchronous commit, enlarging the page cache and widening the connection pool beat two-replica scaling on every metric — from a single machine.
Some infra problems are app bugs
A live database trace exposed a single shared row serialising every write. No replica count or connection proxy can remove a row-level lock — only an application change can.
You can't tune what you can't see
The four SRE golden signals on Grafana turned latency spikes from guesswork into a diagnosis, pointing straight at the layer that was actually saturated.
What I shipped
SRE benchmarking framework
Reproducible k6 experiments with a fixed, staged methodology — the first performance baseline the platform ever had.
CPU-based autoscaler
A Docker Swarm daemon that scales the busiest service between one and three replicas on CPU and queue-depth signals, with cooldown.
Observability stack
Prometheus + Grafana capturing all four golden signals, federated across two VMs so app metrics survive under load.
CI/CD quality gate
A pipeline check that blocks production deploys when tail latency or error rate breach an agreed threshold.