https://www.rambling-me.com/blog A blog to reflect my thoughts, learnings, and observations en-us me@rambling-me.com (Dopeking) me@rambling-me.com (Dopeking) Mon, 03 Aug 2026 00:00:00 GMT https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/1-how-far-request-response-goes https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/1-how-far-request-response-goes The honest defense of synchronous request-response. Before reaching for a broker, most systems have a long runway left in boring, well-understood techniques: stateless services, connection pooling, caching in front of the database, and read replicas. Services scale for free. The database is the ceiling. Knowing how far sync goes tells you when you actually need something else. Mon, 03 Aug 2026 00:00:00 GMT me@rambling-me.com (Dopeking) technologyscalingapi-backendsystem-designrequest-responsecachingdatabasepractitioner https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/2-where-sync-breaks https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/2-where-sync-breaks The point where synchronous request-response stops being enough, and the honest case for a message broker like Kafka. The good reasons are decoupling, load-leveling, fan-out, and durability. The bill is eventual consistency, added latency, operational burden, and harder debugging. And a clear account of when you should not reach for it at all. Wed, 05 Aug 2026 00:00:00 GMT me@rambling-me.com (Dopeking) technologyscalingapi-backendsystem-designkafkaevent-drivenasyncpractitioner https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/3-kafka-mechanics https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/3-kafka-mechanics Just enough Kafka to reason about scale, not a tutorial. Partitions are the unit of parallelism, keys decide ordering, consumer groups divide the work, and partition count bounds throughput. Then the delivery semantics that shape everything downstream: at-least-once versus exactly-once, and what each really costs. Sat, 08 Aug 2026 00:00:00 GMT me@rambling-me.com (Dopeking) technologyscalingapi-backendkafkapartitionsconsumer-groupsdelivery-semanticspractitioner https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/4-correctness-in-an-async-world https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/4-correctness-in-an-async-world The hard part nobody warns you about. Once you go asynchronous and at-least-once, duplicates, retries, partial failures, and the dual-write problem all become your problem. The toolkit: idempotency as the foundation, retries with dead-letter queues, the outbox pattern for atomic publish, and sagas for multi-step flows like payment. Where a bank and a food app draw the line differently. Mon, 10 Aug 2026 00:00:00 GMT me@rambling-me.com (Dopeking) technologyscalingapi-backendidempotencyoutboxsagadead-letter-queuepractitioner https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/5-infra-and-operating-at-scale https://www.rambling-me.com/blog/posts/technology/scaling/api-backend/5-infra-and-operating-at-scale The infrastructure that carries an async system in production. Sharding the data layer past the single-primary ceiling, autoscaling that respects the real bottleneck, backpressure so overload degrades instead of collapsing, and the security and observability that make an asynchronous system operable at all. Closing the backend track. Wed, 12 Aug 2026 00:00:00 GMT me@rambling-me.com (Dopeking) technologyscalingapi-backendshardingautoscalingbackpressureobservabilitypractitioner