Posts

Showing posts with the label System Design

SQL vs NOSQL

Design a Flight Aggregator Service

CAP THeorem

Image
The CAP theorem, or Brewer’s theorem, is a fundamental theorem within the field of system design. It was first presented in 2000 by Eric Brewer, a computer science professor at U.C. Berkeley, during a talk on principles of distributed computing. In 2002, MIT professors Nancy Lynch and Seth Gilbert published a proof of Brewer’s Conjecture. The CAP theorem states that a distributed system can only provide two of three properties simultaneously: consistency, availability, and partition tolerance. The theorem formalizes the tradeoff between consistency and availability when there’s a partition. A distributed system is a collection of computers that work together to form a single computer for end users. All of the distributed machines have one shared state and operate concurrently. With distributed systems, users must be able to communicate with any of the distributed machines without knowing it’s only one machine. The distributed system network stores its data on more than just a single no...

Resiliency | Latency | Reliability

 Resiliency 1) Reliability 2) Error Handling 3) Graceful Failure Ability to handle and recover from failures gracefully. Resilient Solution 1) Detect Failure 2) Recover quickly and efficiently (within seconds or minutes) Resiliency Patterns 1) Circuit Breaker  2) Compensating Transaction 3) Bulkhead  4) Leader Election Latency It is a measure of delay. In a network, latency measure the time it takes for some data to get to its destination across the network. Low latency - Good, High Latency - Bad Reliability The probability of failure-free operation of a computer program in a specified environment for a specified time. Availability The percentage of time that the infrastructure, system or solution is operational under normal circumstances. The mathematical formula for Availability is : Percentage of availability = (total elapsed time – sum of downtime)/total elapsed time

Youtube Design

Image
 File upload flow

System Design URL Shortening Service

Image
URL shortening services like  bit.ly  or  TinyURL  are very popular to generate shorter aliases for long URLs. You need to design this kind of web service where if a user gives a long URL then the service returns a short URL and if the user gives a short URL then it returns the original long URL.  For example, shortening the given URL through TinyURL:  https://www.interviewready.org/get-your-dream-job-with /?ref=leftbar-rightbar We get the result given -  https://tinyurl.com/y7vg2xjl Requirement Before you jump into the solution always clarify all the assumptions you’re making at the beginning of the interview. Ask questions to identify the scope of the system. This will clear the initial doubt, and you will get to know what are the specific detail interviewer wants to consider in this service.  Given a long URL, the service should generate a shorter and unique alias of it. When the user hits a short link, the service should redirect to the origin...

Caching

Image
What is a cache? A cache is a component that stores portions of data that would otherwise either take a long time to calculate/process. Caches may also originate from another underlying backend system, where caching is used to prevent additional requests for round trips for frequently used data. Caching can be used to improve performance or reduce application latencies in both these cases. A cache hit means the data required for the request is in the cache and is served from the cache. A cache miss means the data required for the request is not in the cache and would need to be computed by the backend systems.  Why we should cache?? 1) Reduce network calls. (Store data in cache and return that data to user instead to hit the DB) 2) Avoid repeated computations. (Suppose we want average age of employees, its a costly operation, we should store it in cache) 3) Reduce DB load. 4) Increase the response time. Cache Policy -  When I have to add data ad when we have to evict the data...

LRU Cache Implemetation

Image
 How to implement LRU caching scheme? What data structures should be used?  We are given total possible page numbers that can be referred. We are also given cache (or memory) size (Number of page frames that cache can hold at a time). The LRU caching scheme is to remove the least recently used frame when the cache is full and a new page is referenced which is not there in cache. We use two data structures to implement an LRU Cache.   Queue which is implemented using a doubly linked list. The maximum size of the queue will be equal to the total number of frames available (cache size). The most recently used pages will be near front end and least recently pages will be near the rear end. A Hash with page number as key and address of the corresponding queue node as value. When a page is referenced, the required page may be in the memory. If it is in the memory, we need to detach the node of the list and bring it to the front of the queue.  If the required page is n...

12 Factor App Principles

 12-factor app is a methodology or set of principles for building the scalable and performant, independent, and most resilient enterprise applications. The 12-Factor Principles Codebase (One codebase tracked in revision control, many deploys) Dependencies (Explicitly declare and isolate the dependencies) Config (Store configurations in an environment) Backing Services (treat backing resources as attached resources) Build, release, and Run (Strictly separate build and run stages) Processes (execute the app as one or more stateless processes) Port Binding (Export services via port binding) Concurrency (Scale out via the process model) Disposability (maximize the robustness with fast startup and graceful shutdown) Dev/prod parity (Keep development, staging, and production as similar as possible) Logs (Treat logs as event streams) Admin processes (Run admin/management tasks as one-off processes) Codebase (One Codebase Tracked In Revision Control, Many Deploys) 12-factor app advocat...

ActiveMQ vs Kafka

ActiveMQ is  push  based messaging system and Kafka is  pull  based messaging system. AcitveMQ, Producer send message to Broker and Broker push messages to all consumers. Producer has responsibility to ensure that message has been delivered. In Kafka, Consumer will pull messages from broker at its own time. It's the responsibility of consumer to consume the messages it has supposed to consume. Kafka has a  more efficient storage format . On average, each message had an overhead of 9 bytes in Kafka, versus 144 bytes in ActiveMQ. ActiveMQ Broker had to maintain the delivery state of every message resulting into lower throughput. Kafka producer doesn’t wait for acknowledgements from the broker unlike in ActiveMQ and sends messages as faster as the broker can handle.  Overall throughput   will be high if broker can handle the messages as fast as producer. ActiveMQ is traditional messaging system where as Kakfa is meant for distributed processing system wit...

Continuous integration vs. Continuous delivery vs. Continuous deployment

Image
 Continuous Integration Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch. Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch. Continuous Delivery Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.  This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button. In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever...