Build Vs Buy Messaging Application

Chapter 1 : Product Owner

When it comes to software development, business owners are often faced with the decision of whether to build or buy a product. Building a product in-house can be a costly and time-consuming endeavour, as it requires a diverse set of skills and domain expertise. Additionally, there is a risk of failure during peak load and difficulty scaling the product to meet future demands. On the other hand, buying a product that meets 80% of your requirements and has a stable performance can be a more cost-effective solution. It’s important to consider the complexity, scalability and cost of both options before making a decision.

When developing a product for a specific niche market, thorough research is crucial. As a product manager, it’s important to understand the best technology for the task at hand without compromising the overall system architecture. This may involve using multiple technology stacks or databases. A holistic approach is essential.

Additionally, it’s important to consider the product’s performance during high-demand periods. To ensure the product can handle peak load, it’s necessary to have a specialized team test the product, automate test cases, and design a policy for manually testing complex parts of the application.

Chapter 2: Solution Architect

The process of building a one-bedroom kitchen is vastly different from constructing a large shopping mall. The number of people visiting each of these structures is vastly different. As a solution architect, it’s important to consider the design based on peak load, future scalability, and the cost of cloud infrastructure in terms of CAPEX and OPEX. If the platform cost is high, it can negatively impact overall margins and profitability. The goal is to design something robust, scalable, and cost-effective.

When designing a solution, it’s important to be mindful of the limitations and avoid offering fancy reports that may not perform well when the database size increases. Instead, certain features can be offered on-demand, which can help save resources and improve the overall throughput.

Chapter 3: Meeting the demand of high TPS

Building an app that requires a high number of IOPS for both reading and writing can be a challenging task. IOPS (Input/Output Operations Per Second) is a measure of how many reads and writes a storage system can perform in a single second. A high IOPS requirement means that the app needs to handle a large amount of data quickly and efficiently.

When building an app that requires higher IOPS, it’s important to consider the technology stack and architecture. Choosing the right database, which can help to optimize the read and write performance. Additionally, using a distributed database can also help to improve IOPS by allowing data to be spread across multiple servers.

Another important consideration is the infrastructure and hardware. Using high-performance storage devices such as solid-state drives (SSDs) or NVMe drives can significantly improve IOPS. Additionally, using a cloud infrastructure such as AWS, Azure or Google Cloud can also provide access to high-performance storage options.

In addition, to improve IOPS, one should consider cache mechanism, such as Redis or Memcached, which can help to reduce the number of reads and writes to the database. One can also use load balancer, auto-scaling and other techniques to handle high traffic and IOPS.

In conclusion, building an app that requires higher IOPS requires a combination of the right technology stack, architecture, infrastructure, and hardware. It’s important to carefully consider each of these factors to ensure that the app can handle the high number of reads and writes required.

Chapter 4: The Stack and Skill set

A high-level approach to some of the technologies used in our A2P SMSC

Protocols: TCP/IP, UDP, SCTP, MQTT, HTTP, SMPP, M3UA, SCCP, TCAP, MAP

Database: 2RDBMS, No SQL, Memcached, In memory

Tech Essential: Socket, Stream, Buffer

The App: UX/UI, C#, .netcore, Angular, Nodejs, jQuery, Bootstrap

Network Stack: Reverse Proxy, Nginx, Load balancer layer 3 and layer 4, IPtables, Tcpdump

Delivery: Docker, Kubernetes

Automation: Jenkins, Ansible

Development: JIRA, Git, Confluence, IDE

Monitoring and troubleshooting: Zabbix, Wireshark

Ticketing: Mfluence

Chapter 5: Conclusion

Finally, when developing a product that requires specialized domain knowledge, it is important to have a team with the appropriate skillset. For example, developing a VOIP app and an A2P messaging app are two very different things. Messaging applications require a high number of IOPS due to the high demand for TPS (transactions per second). It is important to understand these differences and have the right team to handle it.

In our experience, it’s generally more cost-effective to purchase a product that meets 80% of your requirements and has a stable performance. Developing something for internal use can be a costly and time-consuming endeavour, as it’s challenging to acquire and maintain a diverse set of skills and domain expertise. Additionally, when building something in-house, there is a risk of failure during peak load and difficulty scaling the product to meet future demands.

If you would like more in-depth information on this topic, you can contact me via Skype at hexwireless.