top of page
Writer's pictureDon Peter

Product architecture failure - Story of how I made one, and looked stupid.


Product architecture is important while building applications


Friends, I would like to share an incident where I failed as a programmer.


I got my first freelance project

After my college days, I began working as a freelance developer. I got my first project from my LinkedIn network. I was in charge of developing both the mobile app, and the backend. The core feature of the app was implemented with a periodic data fetch from the server and displaying it to the user.


And the dreaded moment came knocking

A month of development work, and the application went live. We got some traction. And negative comments started appearing in the Play Store. A good number of users said they were not able to view the data !!!


Tested the app multiple times only to find out that it was working as per the expected workflow. This made us scratch our heads as feedback suggested our core feature was failing. Client started yelling at me during the project calls.


Many days of testing and in-depth analysis, we concluded that the data loss would have occurred due to some raise-condition in fetching and deleting data. The client had suggested removing the data from the server after it was consumed by the mobile app. I communicated the same to the server team and they made sure data is removed as soon as the data is retrieved by the app.


So this is what was happening. App sends a GET request to fetch data. After sending the response, the server then goes ahead and deletes the data. As per plan, yes !!! Now, if there is a network issue or any delay in receiving the response, the app sends the GET request again only to find the data is already deleted.


The app lost customers, and our client dropped the project before we could fix it.


Years passed, And I became a better developer

As time progressed, I started working on multiple programming languages, read RFC specifications and got experienced on software architectural patterns. Working on different products at scale enabled me to understand the need to properly architect a product. As I began to learn more about API design, It made me rethink what actually went wrong in my project.


The first mistake that I made was not recognizing the lifecycle of data that is to be deleted. Once the app receives data from the server, the data should be deleted only after the app sends a confirmation back to the server. The second mistake was that I executed multiple tasks in a single API call. Here, a single HTTP GET call was used to fetch and delete the data at the same time. Using GET requests to delete data goes against the intention of GET in HTTP spec. The app would have functioned smoothly and data loss would not have occurred if one HTTP call was assigned to fetch the data and another call was made to delete the data.


This is just one among the many instances where poor product architecture messed up the product.


Why am I writing this post? Because I see some of the product companies rushing through product development without focusing on the architecture. Spending quality time to understand the lifecycle of data and architecting the solution accordingly helps much. As a developer it will save you from embarrassment.

コメント


Blog for Mobile App Developers, Testers and App Owners

 

This blog is from Finotes Team. Finotes is a lightweight mobile APM and bug detection tool for iOS and Android apps.

In this blog we talk about iOS and Android app development technologies, languages and frameworks like Java, Kotlin, Swift, Objective-C, Dart and Flutter that are used to build mobile apps. Read articles from Finotes team about good programming and software engineering practices, testing and QA practices, performance issues and bugs, concepts and techniques. 

Monitor & Improve Performance of your Mobile App

 

Detect memory leaks, abnormal memory usages, crashes, API / Network call issues, frame rate issues, ANR, App Hangs, Exceptions and Errors, and much more.

Explore Finotes

bottom of page