Learning About Scalable Backend Engineering: My Conversation with Jahongir Rahmonov

I had the opportunity to speak with Jahongir Rahmonov, a software engineer whose professional background is focused on scalable distributed backend systems. This conversation was useful because it gave me a clearer view of what separates ordinary programming from serious backend engineering.

As students, we often build projects where everything runs in one place. A frontend calls a backend, the backend reads from a database, and if it works on localhost, we feel the project is finished. But real systems are different. They have many users, many services, many failure points, and many performance constraints. A system that works for ten users may fail completely for ten thousand users if the architecture is weak.

One of the main ideas I took from this conversation is that scalability is not only about adding more servers. Scalability begins with design decisions. How the database is structured, how APIs are separated, how services communicate, how data is cached, how background tasks are handled, and how failures are managed all affect whether a system can grow.

This matters to me because I am building projects that I want to treat as real products, not just assignments. For example, SejongPulse is a campus communication platform. At a small level, it may only need simple authentication, posts, communities, and messaging. But if it grows, the system needs to handle more users, more messages, more notifications, more data, and more edge cases. That means I need to think beyond the first working version.

We also discussed the importance of distributed systems thinking. Distributed systems are difficult because different parts of the system may fail independently. A database may be slow, a service may timeout, a message may be delayed, or a request may be retried. In small projects, these problems are often ignored. In real engineering, ignoring them creates unreliable software.

A useful lesson from the conversation was that backend engineers need to think in terms of tradeoffs. For example, making a system faster can make it more complex. Splitting a system into services can improve separation, but it can also introduce communication problems. Caching can improve performance, but it can also create stale data. There is rarely a perfect answer. Good engineering means understanding the cost of each decision.

Another important topic was fundamentals. Scalable systems are not built only by using cloud tools. They require understanding databases, networking, concurrency, queues, indexes, transactions, latency, consistency, and failure handling. Tools change, but these concepts stay important. This was a strong reminder that I should not skip fundamentals just to move faster.

This conversation also changed how I think about writing project case studies. Instead of only saying "I built a platform using React and Supabase," I should explain the backend decisions more clearly. How is the data modeled? How are users authenticated? What happens when a user joins a community? How are permissions handled? What parts of the system are real-time? What would need to change if the platform scaled?

Those questions make a project look more serious. They show that I am not only copying UI components but thinking like an engineer.

Another lesson was engineering discipline. In backend systems, small mistakes can become big problems. Bad naming, weak validation, unclear database relations, missing error handling, and poor documentation may not matter in a toy project, but they matter in production. Serious engineers write code that other people can understand, debug, and extend.

For my future learning, this conversation pushed me to focus more on system design, backend architecture, and production-level thinking. I want to become more comfortable with designing APIs, modeling databases, handling authentication properly, using queues, understanding caching, and writing services that can grow.

Overall, my conversation with Jahongir Rahmonov helped me understand that backend engineering is not just about writing endpoints. It is about designing systems that remain reliable as complexity increases. That is the mindset I want to bring into my own projects.

Key Takeaways

• Scalability starts with design, not just infrastructure.
• Distributed systems require thinking about failure, latency, retries, and consistency.
• Backend engineering is full of tradeoffs; there is rarely one perfect solution.
• Strong fundamentals matter more than blindly using cloud tools.
• A serious project case study should explain architecture, data flow, and backend decisions.