Behind the scenes

Today we will be going behind the scenes to understand how software applications are built ground up. A similar, if not the same, format is followed by major tech companies around the world. I think it's a great opportunity for me to share what I have learned over the years at LinkedIn and Expedia and how you can bring a similar software development process to your company or university projects for systemic software development.

Product Requirement Document (PRD)

This is the first step of developing a product or a feature. A PRD is a document that lists the features we want to develop. For large products, It could also talk about the minimum viable product (MVP) and where it wants to go eventually.

This is the document mostly provided by the Product manager/Engineering Lead or both. When writing a PRD it is important to understand following

  1. What value we are trying to provide with the given feature or product?
  2. How it aligns with the north star vision and mission of the company and team.
  3. What are the key metrics we are trying to move with the feature? For example, more revenue generation, or increase in user sessions, or improving user efficiency when using the application, etc.
  4. If developing a client-facing application, we should also check for UXR results which mostly motivate the product in a specific direction.
  5. PRD should also have UX designs for client-facing applications to understand the look and feel of the application.

Engineering Design Document (EDD)

Once PRD is finalized, EDD explains the overall architecture of the software system which accomplishes the requirements in PRD. EDD should mention different software systems we will be creating or leveraging (if already present), and engineering choices made in different layers (Backend, frontend, Databases) of the system with Pros and Cons. If it is a large product, we can also create multiple EDDs focused on each layer.

EDD should include

  1. Overall architecture and data flow: All the building blocks we would need to develop the application. How different Services, Databases (DB), and Clients (Mobile/Web) would communicate with each other and how data will flow throughout the system.
  2. Non Functional requirement: Design choices between NoSQL vs SQL, data replication, and sharding (if not provided by your company infra or cloud provider), Request Quota limit, etc. Tech stack choices if you trying to adopt a new stack over an existing tech stack.
  3. Services and API: Define the data schema of different entities and their relationship. All the services and APIs we will build or leverage to send data back and forth between the clients and other downstream services or DB. APIs will be exposed to clients and services and APIs used for interservice communication. Data massaging to solve over-fetching/under-fetching of data. What is the expected QPS for each API, rate-limiting/throttling mechanism
  4. Clients: Discuss the client side work like spinning up a new web/mobile app or using the existing one. Different components to be built and how they can scale for future iterations of the project. Different APIs clients will communicate with to get the data and render the screen.
  5. Tracking: The key things we will be tracking to generate the product metrics to determine the success or failure of the project.
  6. Alerting and Monitoring: Alerts and monitors we need to add to determine the overall health of the system. Appropriate alerting and monitoring are crucial to keeping the lights on in Production.

Once EDD is finalized it needs to be reviewed and approved by the engineering teams involved in the product

Capacity Estimation

Based on the traffic and QPS we expect for a system, we need to estimate how many machines will be required to serve those many requests. Also, need to figure out the up-scaling and down-scaling of the system based on the traffic. Usually, large companies have Site Reliability Engineers who can help with capacity estimations.

Security

If the system is working with sensitive data or exposing new API to the public, it needs to go through a security review to validate if the design choices made in EDD are secure and robust enough to protect data and systems.

Ramp Strategy

How we will release the new product to the users. We need to target a user base from where we can get early feedback on the product. It helps to determine whether we need to do some improvements before we ramp to other markets or if we can go with the same version.