Assume you’ve to build a payments application supporting multiple payment options such as UPI, credit card. Each of these payment option state is synced using callbacks and synchronous APIs with the payment providers.

Guideline of Isolation: Build it Modularly

The system should be built as modules with each module being independent on its own. This helps with maintainability and reusability of modules.

Example includes keeping independent modules for different payment methods and separate module for callback processing. You can keep the common stuff in common module which can be imported as needed.

Guideline of Simplicity: Keep it Simple, Silly

You should always avoid unnecessary components. Only build what’s really needed. Iterate over the implementation - always test and improve.

Examples include trying to support a lot of payment methods in the beginning or thinking of going global on day zero. This could create extra churn and gets the project delayed.

** The NOTES in this blog are taken from Chapter 01 of System Design on AWS. Explore the book:

📕 O’Reilly: https://oreil.ly/ruQbc

📕 Amazon.in: https://amzn.to/4jExkte

📕 Amazon.com: https://amzn.to/3D3BIBJ

Guideline of Performance: Metrics Don’t Lie

Metrics (observability) are really important. They helps in debugging as well as how well your system is doing.

Example metrics include time taken for payment processing and payment failure rates.

Guideline of Trade-offs: There is no such thing as Free Lunch

Every choice has trade-offs. There are pros and cons with every approach. Choose what makes sense for your business use case and to your product’s scale. Take inspiration from others but don’t follow blindly.

Example, thinking of independent micro-services from day one because you can scale them independently. Well yes, but who will manage this?

Guideline of Use-cases: It Always Depends

The design of system can depend on a lot of factors. Some of the factors include system requirements, user needs, expertise, budget and regulations.

Reiterating from previous point, choose what works for you. Here is summary image (generated with Grok AI)

Happy Building!

General Thoughts on Compute Selection

• If you’re working in a company, the selection of compute is generally influence by what’s being already being used in other projects/services. This is because the team already has experience managing certain technology. Introducing new services brings in learning curve and extra operational burden.

• For reference, the comparison of services is corresponding to AWS cloud but they hold across the cloud providers.

Let’s start the discussion, starting with virtual machines.

Elastic Compute Cloud (EC2)

There are two options with Amazon EC2. A shared tenancy or dedicated tenancy. The idea is you wish to buy the entire physical server or just a part of it. Most of needs are served with shared tenancy, don’t worry the customers workloads are properly isolated.

Once you decided on the tenancy (default is shared), the second choice you’ve to make is instance type. This depends on a variety of factors such as:

• Hardware and performance characteristics of an instance such as CPU, disk, memory and network.

• Type of workloads such as huge AI training workflows vs running a web application.

The third selection choice you’ve to make is billing model. There are three types, reserved, on-demand and spot instances. The default selection is an on-demand instance.

• Reserved: If you’re aware of scaling needs, you can pre-order the number of instances needed. The reserved instances are available at a discounted price.

• On-Demand: You spawn the instances when needed and terminate once done. This is default pricing model.

• Spot: For less critical workloads where uptime is not a hard requirement, spot instances could be chosen. You can bring up an instance but AWS can terminate it at anytime they wish.

The content of this blog is influenced by Chapter 11 of O’Reilly book System Design on AWS. Checkout the book at https://msdeepsingh.com/books/system-design-on-aws/.

Let’s move to second compute option, containers.

Containerisation Services

The major problem that occurs in development is “it works on my machine”. The development environment could vary from engineer to engineer, from local setup to production environment and so on. This problem is solved via containers.

Another problem addressed via containers is optimising the resource usage on EC2 machines.

You package the application binary with all the dependencies and the same container can run on any machine. You can deploy these container images and manage them on your own but it’s hard job. So there are multiple orchestration tools built on top to manages the containers at scale, such as Kubernetes.

AWS offers two container orchestration services, namely Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS).

Both of these services comes with two forms of deployment, either we can choose to deploy via EC2 or let AWS manage everything behind the scenes (serverless), called as Fargate. Let’s move on to next choice, Function-as-a-Service.

Serverless Functions

You just write functions and don’t worry about underlying infrastructure at all, everything is managed by the cloud provider. For example, AWS Lambda.

The code you write in functions can be invoked with the help of a trigger. For example, whenever there is new object uploaded to S3 bucket, read the object and perform some analysis.

Decision Framework

From earlier blog on this newsletter on choosing a database, the factors are applicable for compute selection as well.

The decision factors include:

• Solves the use case

• Previous Expertise

• Cost

• Battle-tested software

• Cloud Managed vs Self Managed (Operational Overhead)

• Time to Market

With all this information, let’s conclude our discussion.

Closing Remarks…

Use the below table as reference for selection of compute along with some decision factors discussed in previous section.

In summary:

• All compute options can work at high scale. Evaluate on what works for you. Do PoC if you’ve money and resources.

Iterate on design if you require more control over time.

• Example started with EKS Fargate

• Move to EKS EC2

• Migrate away from managed offering and deploy your own EKS cluster to manage containers EC2 instances.

Taking an example of Amazon Prime video monitoring architecture. The distributed architecture involved multiple AWS Lambda functions orchestrated via AWS Step Functions. This led to lot of operational overhead with extra dollars to spend. The team rearchitected the system by migrating to ECS. This saved cost plus network latency between the components of distributed system.

See you next week! Don’t forget to subscribe :)

Subscribe now

Problem Statement

Now think of a same scenario for a system or a component of a system. If a large number of requests arrives at once trying to acquire a resource, the system will be overloaded if not handled well. The sudden traffic spike can cause issues like high CPU utilisation, memory leaks, etc.

Thundering Herd is often used in-relation to cache and databases. For a cache-miss scenario, all the requests trying to access same item will be routed to the database. This overloads the database if database is not scaled to handle this load. This causes a cascading failure in the system bringing down the entire system.

Resolution

The resolution has two directions, one is mitigation (come out of situation if thundering herd occurs) and other is prevention (system is designed in a way so thundering herd doesn’t occur). Let’s explore both of these directions.

Thundering Herd Mitigation

It’s really hard to come out of Thundering Herd situation. This can cause cascading failures and bring the entire infrastructure down. The best is dropping the user requests. This could be for all the users or a percentage of users depending on the situation.

The database might have queued up all the requests, so restart the database. Same applies to other infra components.

Thundering Herd Prevention

The system can be designed in a way ensuring it can come out of these situations easily if they happen and enhancements ensuring this situation doesn’t happen.

Discard Requests

The first solution is load shedding. Serving some requests is always better than serving none of them. This is the idea behind load shedding because an overloaded system can cause cascading failures.

Here are few suggestions on discarding requests:

• Discard lower priority requests. This could be some back-office jobs that can be scheduled for later point of time.

• Discard % of user requests. If above doesn’t help, the system should drop some percentage of user requests.

• Keep a request buffer. The requests are put in a queue for certain time and served if capacity is available (or system recovers).

Watch the dive deep on Uber’s Load Shedding Framework QALM (QoS Load Management Framework) and Cinnamon architecture (Part I, Part II, Part III) for discussion on how these systems are built.

Jitter in Retries

If a request fails, what you do? Hit the refresh button. The retry could be user enforced (such as refresh) or system invoked on request failures. Retries are great to recover from transient failures but this can overload the system in case of thundering herd scenarios.

If the system is not able to process the requests, and all the users retried at the same time. This makes the situation even worse. Introducing Jitter means there is random lag between the retries ensuring not all requests arrive at the same time.

Exponential backoff in retries is only good if applied with Jitter else it doesn’t solve the problem it is supposed to. In summary, don’t retry at fixed intervals. Jitter is must, exponential backoff is good to have.

What’s Important Should Stay Alive?

Big software architecture has a lot of components (or services). Each component does some job and might depend on other components for part of the job. There are also some good have components. Take an example of video feed generated by Netflix, it’s customised for an user.

In overloaded system scenarios, it’s ok to reflect same video feed to all users and stop the work from recommendation system. This is good to have and not critical. The critical component is video play. The video should start once user clicks on play button.

The recommendation is clear division between the services. General criteria followed by many companies is tier strategy. Tier 1 service is most critical, Tier 2 is less critical and so on.

The chaos and stress testing should focus majorly on Tier 1 services ensuring system operations in unknown scenarios.

Scaling

Automated Scaling is one of suggestions that floats around to unburden the servers from this load. For thundering herd, it doesn’t help much. Bringing up a server takes some time (even with light-weight application binaries and low startup time).

Pre-scaling is one recommendation if you’re aware of some upcoming event and loosening up the auto-scaling thresholds so the system doesn’t wait for hit upper bounds can help.

Request Coalescing

We discussed thundering herd occurs if a huge number of requests are trying to access the same resource. Can we deploy a mechanism so as only one request is processed and others wait for for its results, see Figure 1.

Figure 1 Request Coalescing

All the requests are trying get(x), only one request actually fetch the result and rest of them use the same. This shields the backend systems, resolving thundering herd issue. At the caching layer, this problem is solved with a cache promise.

Cache Promise works on the similar concept, it stores a promise till the results are retried by the primary query and other requests wait for this promise. Once the promise is fulfilled, all requests are served.

Interested in practical implementation of these concepts, STAY TUNED. Something exciting is coming — https://msdeepsingh.com/books/

Further…

• How to avoid thundering Herd?

• Instagram Architecture: Solving Thundering Herd with Cache Promise

The primary motivation for writing a technical book should not be money. If it is, you should probably reconsider. Technical books have a highly niche audience. With the rise of AI tools, fewer people rely on books for technical answers.

Financial gain was never the motivation for me, so what inspired me to write “System Design on AWS”?

• Personal Growth: Taking a complex idea and translating it for beginners forces you to deepen your own understanding.

• The Communication Challenge: Having deep technical knowledge is common, but delivering it effectively is rare. Writing the book was a test of communication and documentation skills. I credit much of this to the writing culture at Amazon.

• Building Trust: Being an author with a respected publisher like O’Reilly acts as a powerful credential. Much like having a top-tier university or top company on your resume.

Is It Really Worth It?

Absolutely, but the ROI is in your network, not your bank account. As the saying goes, “Your network is your net worth.” Publishing the book opened doors to connect with industry leaders, CTOs, and senior engineers. I’ve been invited to multiple conferences to share my insights so it has been my way of giving back to the community. The connections allow you to learn from other leaders’ failures, successes, and decision-making processes.

Adding to above, it’s not like you’ll make nothing. The idea is not setting high expectations on monetary terms.

Project Initiation

Me and my co-author Jayanth Kumar took close to 2.5 years to finish the project. The details outlined as part of this blog are specific to O’Reilly but it’s similar with other technical publishers as well. I’ll divide the process into multiple phases from initial thought process to hard copies in my hands.

Proposal Submission

Starting out is always hard. Jayanth shared this idea with me and had some details already put up in the proposal. We brainstormed among ourselves on the structure of the book so as readers are hooked to the content throughout.

You can find all the details on the O’Reilly Work With Us page regarding different ways you can contribute.

The Proposal Details

Here is the high level description of what you need to fill in the proposal (make a copy of proposal from here).

• Book title and subtitle: The title of the book. For subtitles, you can also suggest multiple subtitles and decide later what works best.

• About the Author: This is basically an author biography and why do you feel you’re the best person to write the book on a particular topic. You can include your past work such as your industry experience, previous technical books/blogs/videos, speaking at conferences, etc.

• Marketing Description: This is something you find on the back cover of the book. You’re basically pitching to buy the book to a potential reader.

• About the topic: This section explains the book title in detail and why it’s important.

• Audience: Who will read this book?

• What the reader will learn: There is always some end goal if you’re selling a product. If the reader finishes the book, what kind of knowledge gain happens and how/where the reader will apply this knowledge.

• Competing titles: If there are similar titles in the market, how this book differs from them and what new values this book specifically offers.

• Book outline: Here you include a detailed chapter-wise table of contents.

• Schedule: How much time will you take to finish the first two chapters, half manuscript and full manuscript. Keep in mind that life happens and if you’re working on the book writing along with your full-time job then keep a buffer.

Balancing the content takes effort, what you go into the book and what should be skipped is the decision you’ve to make. Be ready to spend so much time on choosing topics to be included as part of the book and then again striking them off because you found other things which are more important. Once the draft was ready, we directly emailed one the Content Acquisition Editors from O’Reilly.

Proposal Submission Timeline

We were hopeful of the proposal approval as we firmly believed this is a unique book and solves a lot of gaps in the content already available in the market. Good things happen if you’re hopeful, and we received a positive response to the proposal. At this point, it’s not 100% approved but the acquisitions editor will work with you to modify some details as needed. For example:

• We had a lot of discussion if Part II of the book (AWS specific content) should be included or not. The point being made was there is already a lot of AWS documentation available on the internet, so what new value does the book bring? We finally agreed to keep it so readers can find everything at single place and they are able to follow along from Chapter 1 to Chapter 21. You don’t want to ask the reader to go read on internet about a specific AWS service and then come back to the book on how it’s used practically.

• We had 15 chapters in Part III of the book in the initial proposal which was trimmed down to 8 later. As I was saying earlier, you’ll have to balance the content.

TIP: We also wrote one chapter from Part III and shared after proposal submission on how we’re envisioning the content. I later scrapped it off and wrote it from scratch but if you can, it’s a good idea to have some content ready from the chapters.

After all this communications, the proposal was officially approved and we were presented with a contract to sign. Once signed, the actual work started.

Book Writing Process

You’re assigned a development editor to work with you throughout the book after contract signing. In the first meeting, the development editor shares details like:

• Writing tool: You can either write in Google Docs or O’Reilly has an in-house tool called Atlas.

• Development Schedule: You agree on a chapter-wise schedule on when the chapters will be ready.

• Writing Style: Details around illustrations, writing style, content structuring, etc.

Once you finish a chapter, you share the chapter with the development editor. The role of development editor is to share feedback on the first draft. You work on the shared feedback and it becomes a continuous loop for all the chapters.

After development review is done and feedback is addressed, the chapters are published to O’Reilly platform in early release form. The good thing is people can read chapters early and share reviews on the platform. It’s much similar launching a product MVP, gathering feedback and improving on it before the final launch of the product.

In parallel, the book chapters also goes through technical reviews. For technical reviews, O’Reilly has their own reviewers and you can also suggest from your network. The technical reviews are phased into generally 3 parts, first two chapters, then half manuscript and then full manuscript.

After development and technical review completion of the chapter, the next step is the production phase.

Book Production Phase

A production editor walks you through the book production timelines and different stages as part of this process. Here are few things taken care of as part of this phase:

• Copy Editing: A copy editor goes through the entire manuscript to make sure it matches the O’Reilly style guidelines. This stage generally doesn’t require too much input from your end. This is divided into two parts, QC1 and QC2. You can suggest anything as part of QC1 and that is addressed as part of QC2.

• Illustrations: In parallel to copy editing, an illustrator works through the images and recreates them as per O’Reilly style. You can work through the illustrations for any suggestions from your end.

• Index: An indexer is assigned to the project responsible to create the final index of the book.

The book is ready to go to print after all these steps as part of the production phase. The final version of the book is available within a week on O’Reilly platform and it generally takes 3-4 weeks for physical copies to be printed out.

Let’s talk a little about the book I wrote with O’Reilly - System Design on AWS.

System Design on AWS

System Design on AWS was written with a clear philosophy: to be useful both “during the interview and after the interview.” It is designed to take your knowledge beyond basic whiteboard theory so you can make effective long-term architectural decisions when building actual products.

Book Content

• Part 1 - Fundamentals: Covers core distributed building blocks like load balancers, caching layers, databases, network protocols, containerisation and general architecture patterns.

• Part 2 - AWS Services: Maps out the specific AWS services available across different operational domains (compute, databases, networking, event-driven, observability, big data, machine learning etc.).

• Part 3 - Practical Implementation: Focuses on real-world system design philosophy. It walks through building complex applications from scratch such as a stock broker platform or a hotel reservation system. From gathering initial requirements to deploying the actual AWS components. It emphasizes that drawing boxes on a whiteboard is not enough; you need to know how to actually run the system.

You can find everything about the book on https://msdeepsingh.com/books/

Get System Design on AWS

📕 O’Reilly: https://learning.oreilly.com/library/view/system-design-on/9781098146887/

📕 Amazon.in: https://amzn.to/4jExkte

📕 Amazon.com: https://amzn.to/3D3BIBJ

📕 Amazon.co.uk: https://amzn.to/3QW6Fvf

📕 Shroff Publishers (Indian Subcontinent): https://www.shroffpublishers.com/books/9789355428035/

Before closing, I want to share my opinions on the choice of publisher.

Self Publishing or Publishing House?

Self publishing means you’re already well-known in the industry and people will buy the book looking at your name as author. If you’re a first time author like me, you’ve to give some reason to readers so they can trust you. O’Reilly solved this problem for me. O’Reilly is a trusted name and they don’t publish random jargon, the book goes through a strict process so readers clear the first barrier of buying the book.

Also, we were not aware of the overall process. You’ve to spend some additional time on marketing, content reviews, copy editing, etc which are taken care of by O’Reilly in-house. Given we both had full time jobs, O’Reilly was the preferred choice and I’m very glad we pursued this project.

On a closing note, writing a technical book may not make you a millionaire, but it will sharpen your communication, expand your professional network and strengthen your domain expertise.

Best of Luck!!!

You can reach out to me on LinkedIn for specific queries.

Decision Flowchart

Let me take a reference from my O’Reilly book “System Design on AWS” Chapter 3. Figure 1 shows a flow chart on how can you navigate through the choice of database over multiple options available in the market.

Figure 1 Decision Flowchart for Database Choice

The question that comes to your mind, can I follow this flowchart blindly to answer database choice questions? The answer is NO. In Software Architecture and design decisions, there are always trade-offs with any direction you go with. So saying, a particular database is perfect is wrong. In addition to the above flowchart, database choice should be combination of below factors:

Business Requirements

The most important decision criteria is that the database choice should meet the requirements. All other things comes later.

You can start by looking at data access patterns. The databases such as DynamoDB only makes sense if you know the access patterns. If there so many joins required, and you don’t what kind of queries will be there, relational database is better choice. This can very much happen for a new project or a startup; relational database is good choice to start with.

Don’t forget to checkout the “System Design on AWS” book for detailed dive deep on relational, non-relational databases and how best to use them.

Everything about "System Design on AWS"

Previous Expertise

If you already have expertise with some technology then you know how to use it in the best way possible. If something meets the requirements and you also have previous working experience, nothing beats this combination.

In case you’re new to databases or your use case is totally new, try to stick with battle-tested software. If a lot of people have used something at scale already, you’ll get ton of support from community.

Cost

You should be able to afford something to use it. Cost is important consideration, this is mostly applicable to managed offerings. When it comes to cost, I recommend to look at total cost of operations and not just the monthly bill paid to the provider.

See,

• How much time you’re saving in launching your product by leveraging managed offering. This is also applicable to other solutions as well and not just databases.

• How much operational burden it takes off from your plate.

With this, let’s conclude the discussion.

Conclusion

Always consider trade-offs for any decision you make, what are the pros and cons for any choice being made. Also, there is thin line between database features these days. There are a lot of managed relational database offerings with horizontal scaling support so you don’t have to implement this in-house. There are a lot of non-relational database offerings with transactional support.

I’ll recommend to choose non-relational only if you know you need it. Else stick to relational databases, they solves most of the requirements. Happy Building!

Check out the YouTube video for the discussion with the community -

As I was going through the book, I created chapter-wise short notes and YouTube videos as a summary.

DDIA Chapter 1-12 Notes

70.1MB ∙ PDF file

Download

Chapter-wise summary of Designing Data-Intensive Applications book

Download

Watch on YouTube

Should you read the book?

An excerpt from the O’Reilly around usefulness of the book

• Peer under the hood of the systems you already use, and learn how to use and operate them more effectively

• Make informed decisions by identifying the strengths and weaknesses of different tools

• Navigate the trade-offs around consistency, scalability, fault tolerance, and complexity

• Understand the distributed systems research upon which modern databases are built

• Peek behind the scenes of major online services, and learn from their architectures

Where can I get a copy?

• amazon.com

• amazon.in

• O’Reilly online

• ScyllaDB sponsored chapters for free

Figure 1. Train booking application

There was something interesting about the project. There was no underlying database. The data was directly dumped to files, including login details, train details, booking details, etc. Example, train details for sun stored in sun.txt. Checkout code on Github - https://github.com/msdeep14/irctc

1 2 12956 jp-pune_exp 3:20PM 51 587
2 1 12957 jp-pune_exp 9:15AM 87 501
20 21 19876 goa_exp 5:00PM 54 709
3 2 10786 jhelum 5:25PM 112 654
1 9 11760 jp-mumbai-exp 2:00PM 67 543
1 2 34561 premium 11:00AM 45 1700

So I think I’m eligible to answer the question; why do we need database if you can store data in files?

Bottlenecks

If there is already classic file storage available, what’s the need for all kind of databases? Let’s take an quick example, you wish to get all the trains from Jaipur to Pune:

• The code snippet above shares trains availability as per source to destination. The beginning two numbers are keys mapped to locations.

• Essentially, you’ll pick the file for a day and find the train.

• What if there is no direct trains? It constructs a graph from file data and finds the trains matching to source and destination.

It’s works all great for college project because there is not much data but soon it will face problems:

• Increased latency

• Supporting different query patterns

Introducing Databases

At a very high level, databases offers structured way of accessing the data. Depending on the use case, the data is stored in a way that it’s retrieval is fast. There are different kind of databases depending on the requirements. Chapter 2, 3 & 10 of O’Reilly title “System Design on AWS” explores multiple databases with their architectures.

Here is a diagrammatic representation:

Figure 2 Decision Flowchart for Database selection

Let’s take an example from train ticket booking. Instead of storing the data in the files, if it’s stored in relational database such as PostgreSQL then it makes easier. For the query pattern, get all the trains from Jaipur to Pune. The point of consideration was how can we skip the reading all the records. The database indexes can be created location and time wise, reducing the data footprint.

Figure 2 offers some clarity on decisions can be made. Further, database choice is not just the use case, it’s combination of all below factors. This is also covered in YouTube channel video.

• Solves the use case (read/write access patterns)

• Previous Expertise with the database

• Cost

• Battle-tested software

• Cloud Managed vs Self Managed (Operational Overhead)

• Time to Market

Watch on YouTube

Subscribe now

The architecture evolves over time and the idea should always be we’re able to iterate over it.

• It’s nice when you get stuff right the first time but we don’t need to

• As long as you get the architecture as right as possible; the implementation stuff isn’t going to be big of a deal

This article captures the very early architecture of Facebook, how it started and challenges faced with scaling.

Initial Architecture

Facebook was launched in February 2004 with focus on connecting people for one school

Tech Stack

• Programming Language: PHP

• Database: MySQL

• Apache Web server

Figure 1 Early Facebook Architecture

The simple architecture served well for single school, but soon there were challenges with more interest and increasing scale.

Scaling Challenges

Let’s discuss few of the challenges faced due to architecture limitations:

• Privacy: Data and feed separation between the schools

• Traffic Distribution:

  • How the data should be distributed for different schools

  • Some schools have heavier usage as compared to others.

• Figure out friends connections with higher degree (friend-of-friend or friend-of-friend-of-friend)

Let’s discuss on the improvements in the architecture to handle the bottlenecks.

Improving Architecture

The key aspect is hiring more and more smart people and give them independence to work on the improvements.

Onboarding More Schools

The first thing that comes to mind for handling more traffic is adding more machines.

• We mentioned web server and MySQL coupled on same machine, so the idea is to decouple the storage from application server and introduce load balancing between the machines.

• This also removed single point of failure. Consistent database layer ensures traffic can be served from any operational machine.

Handling Friend-Of-Friend

If you wish to figure out friend of a person, it’s a direct query to database. For friend-of-friend:

• Retrieve friend list of a person

• Iterate over this list and get friend list of all the items

• This becomes n*n operation.

For friend-of-friend-of-friend, it becomes n*n*n operation; so it’s compute-intensive. The current architecture uses dedicated graph database, but back then:

• Split the database and create one instance of mysql database for each school in the network

• How does this help? Now you’ve to compute n*n*n for 10k (approximate number of people signed up from one school) instead of n*n*n over 6 million (all people across the schools)

The above is in addition to decoupling application servers and database compute. This helped a lot but further the traffic was reaching 100 Million pages/day, a query approximately takes 2-4 milliseconds. The problem lies in each page repeating on the same queries.

Improving Database Performance

What comes to mind to solves the same query problem? Cache the results to avoid hitting the database. Facebook introduced Memcached as caching layer; this brought down query performance to 0.3-0.5 milliseconds.

There were couple of issues though with the distributed architecture of memcached instances; If a memcached instances go down:

• There is no redundancy on information.

• Cache miss occurs; and all the traffic routes to database.

Facebook introduced photo sharing feature, let’s discuss on how it’s implemented.

Photo Storage

From early stage, Facebook chose to smaller machines instead of one big machine. The disk is relatively slow but stable, to overcome the slowness:

• High RAM Caching machines to hold most of the thumbnails and frequently accessed images.

The space consumed by photos is on higher side, some issues uncovered:

• If you wish to upload a photo album with 30 photos (3 MB each), then 90MB is total size; Networking issues with slow internet.

• Router used was built to support 1GB at a time.

Solution:

• Built Java applet and ActiveX control to couple the choosing of photos

• Compression at client side.

It helps:

• Upload photos quickly

• Resource optimisation - less server CPU utilisation

Even with caching machines, transferring images to users takes time. So the solution is to move caching near to users, aka, Content Delivery Networks (CDNs).

Conclusion

Follow Iterative Design Process; Remember you don’t have built it right (or perfect) the first time. Happy Building!

Subscribe now