Retry, Timeout, and Backoff: When Should We Stop Retrying?
Retrying a failed request seems reasonable. But what happens when our retries increase the load on a service that is already struggling to recover?
Emre Görgülü · Software Architect · Systems Architect · Technical Consultant
Understand systems. Design. Build. Evolve.
Beyond writing software.
For over 30 years, I have worked across industries on the analysis, design, development, integration, and technical leadership of software systems.
From enterprise applications to industrial platforms, my experience has taught me to consider technical requirements alongside business needs and operational realities. Whether building new systems or improving existing ones, I focus on solutions that are practical, reliable, and sustainable over time.
Field SystemsDevices · Automation · Telemetry
Enterprise SystemsBusiness Apps · CRM · Healthcare
System IntegrationAPIs · Messaging · Protocols
Application ServicesBusiness Logic · Distributed Systems
Data ManagementData Flows · Consistency
AI-Assisted SolutionsAnalytics · Automation
My Approach
Understand the problem before choosing the technology.
- Problem & GoalsWhat are we solving, for whom, and why?
- Conditions & ConstraintsWhat are our technical, operational, and business limits?
- Alternatives & ImpactWhat are the options? What are their risks and long-term consequences?
- Architecture & TechnologyHow do we design and deliver the solution that fits the need?
Observe · Learn · ImproveOnce decisions are in place, the system's real behavior is evaluated and revisited when needed.
Technologies, development practices, and architectural approaches keep changing. Yet the questions worth asking at the beginning of a project remain remarkably consistent: What problem are we actually solving? What constraints are we working within? How will today's decisions affect the system tomorrow?
Working on projects of different sizes has taught me that delivering software that works is only part of the job. A system should also be maintainable, observable, safe to change, and dependable under real operating conditions.
That is why I evaluate architectural decisions not only on technical merit, but also in light of business objectives, team capabilities, operational requirements, risks, and long-term costs. To me, a good solution is not necessarily the one built with the newest technology; it is the one that best fits the problem and its constraints.
Areas of Expertise
Software Architecture & Modernization
Architectural design for new software systems, technical assessment of existing platforms, modularization, technical debt management, and incremental modernization. I consider how architectural decisions affect development, maintenance, and day-to-day operations.
Distributed Systems & Integration
Designing reliable communication between services, applications, and data sources, with attention to data flows, consistency, fault tolerance, and observability. Integration is not just about connecting systems; it is about making sure they can work together dependably.
Enterprise & Industrial Software
Enterprise applications, field devices, telemetry, automation, and systems that bring together multiple communication protocols. My experience includes software development and integration that bridge central platforms and the realities of field operations.
Artificial Intelligence & Emerging Technologies
I explore and apply AI-assisted development tools, intelligent system designs, and ways to integrate AI capabilities into existing software platforms. My focus is on evaluating their technical potential alongside reliability and practical value.
Industry Experience
Different industries. Different constraints. Shared challenges.
Although the industries I have worked in differ, many of their engineering challenges are familiar: reliable data exchange, interoperability, operational continuity, adaptability, and maintainability.
- Healthcare systems
- Hospital information systems, HL7-based data exchange, and integration across healthcare applications.
- Energy & industrial systems
- Distribution automation, field devices, communication protocols, SCADA, and telemetry platforms.
- Public sector & enterprise applications
- Enterprise workflows, CRM, and systems that require different applications to work together.
- R&D & technical leadership
- Technical planning, architectural decisions, software project delivery, and coordination with development teams.
Over time, I plan to share relevant lessons from this work through technical articles and case studies, while respecting confidentiality obligations.
Articles & Technical Notes
Sharing experience. Examining decisions.
Here I share notes, research, and technical perspectives on software architecture, distributed systems, enterprise and industrial software, and artificial intelligence.
My goal is not simply to explain how a technology works, but to explore why it might be chosen, what alternatives exist, and what those choices mean in real systems. Where useful, articles will include concise code examples, diagrams, and practical experiments.
Transactional Outbox: A Database Commit Doesn't Mean the Message Was Delivered
In distributed systems, committing business data and publishing the corresponding event are two operations with different failure points.
Idempotency in Distributed Systems: Why Is It So Easy to Process the Same Request Twice?
A timeout does not necessarily mean an operation failed. That uncertainty is often the real challenge behind designing safe retries.
Let's Work Together
Let's discuss your technical challenge.
You may be planning a new software system, reviewing the architecture of an existing platform, or looking for a practical approach to integration or modernization.
I can contribute through software architecture and technical assessments, project-based development, system integration, and technical leadership. We can start by discussing your needs and constraints, then determine what form of collaboration makes sense.