SYSTEM DESIGN PHASE 0 PART-3 DAY-4: REST API, GRAPHQL, gRPC: I think almost everyone knows what is api so i would just skip introducing what is api and how does it works we will only look for how much diffrent type of apis works. REST-API: Well it stands for Representational state transfer or sum shit idc just focus on practicals. Widely used in most of the basic CRUD apps, like a todo and all. Rest api is a go to for every developer who wants to build backends as a beginner and so on. Problems with Rest - Rest apis are overfetches means it returns data we dont even need. for example You want a PFP+Comments of a user right? You called your serevr with this request user/profile/121 for pfp and for comments user/comments/121 This will return stupid data with it which you dont even need like createdAT, updatedAT, ID, and all the metadata. GraphQL: This is the type of API which solves the problems of underfetching and overfetching, basically returns the data you only need. it doesnt even need multiple endpoints like rest to return the data. it has a single endpoint which returns the data you defined. Thats all. GraphQL is basically is a part of META internally developed by meta for facebooks and later in 2012 they made it public. Caching is hard in graphQL and there are performance issues aswell. gRPC by Google - This is high performance service to service communcation developed by google, this type of communcation is best for microservices communication. It is mostly like writing a function on another server. Strongly typed, binary, extremely fast. How does this works? Grpc just called the method above and directs to the server Client calls a method, Data serialized using Protobuf - HTTP/2 transport - Server responds with binary data. This is extremely fast and stable. Tradeoffs? yea there is hard to maintain and debug and its not browser friendly at all. Why to even use it? because its fast and poweful replaces rest api in many cases like small typing, streaming support , small payloads. This was the whole post about REST , gRpc and GraphQL in System Design. I hope you like it and yeah the post is smaller because if writing goes in depth there would be a only post about a particular api. I hope you understand. Thanks for reading :)

SYSTEM DESIGN PHASE 0 PART-3 DAY-3: Networking Fundamentals: Why Networking Is Imporant in System Design: Networking is a foundational element of system design because it provides the communication backbone that connects different components of a system. whether they are in the same physical location or globally distributed. A well designed network is crucial for ensuring the system's performance, reliability, scalability, and security. There are two main protocols which are widely used in the world and are basically backbone of the internet. TCP and UDP TCP stands for Transimission Control Protocol and UDP stands for User Datagram Protocol. Before HTTP, Everything rides on transport protocols. TCP: TCP protocol is reliable but slower because of three way handshake SYN-SYN_ACK-ACK. But this protocol gurantees data arrives in order , lost packets are retransmitted and data arrives only once. Basically TCP is more reliable. mostly used for APIs payments, logins and file transfers. UDP: UDP protocol is fast af but it is unreliable. it doesnt guarantees reliability, packets may drop, order not guarantees. This protocol is mainly used for online live vide streaming, video calls and real time communications like WEBRTC. Basically UDP is fast and being fast doesnt guarantees reliability , losing a frame is OK but waiting for retransmission is NOT. Basically TCP prioritizes correctness and UDP prioritizes speed. Why HTTP (Hypertext transfer protocol) exists? TCP only moves bytes and http defines meaning like what the type of data is and what is its intent. Like it tells you status codes , headers, methods like GET,PUT,POST,DELETE. Now lets move forward towards HTTP 1.1, its is simple but slow because it allows only one request per connection. Problem ? if request 1 is slower reques 2 waits. For example browser loading HTML, CSS, JS ,Images each request block others. resullts in high latency. HTTP/2 changed everything allowing multiple requests are sent parallely it involved multiplexing. Why multiplexing matters means it allows multiple reuqest to be sent in parallel, not sequentially. Results? Faster page loads, fewer tcp connections, lower latency. But it still suffers from TCP head of line blocking if one packet is lost all streams wait. HTTP/3 built on UDP (QUIC) it uses QUIC which runs on over UDP, Why QUIC? tcp's reliability is great, but for modern internet needs QUIC provides encryption, faster handshakes, no tcp head of line blocking, independent streams. benefit is that packet loss in one stream doesnt even affect others. it makes page loads faster, better mobile performance on poor or weak networks and its ideal for global systems, used by google, netflix,meta etc. In Real Engineering HTTP/1.1 is legacy. HTTP/2 for modern REST and GRPC. TCP based correctness matters. Real Time Systems UDP WebRTC Custom protocols Global Scale Platforms HTTP/3 CDN + QUIC Edge computing HTTP/1.1 is simple but slow, HTTP/2 fixes parallelism, and HTTP/3 fixes latency by ditching TCP’s limitations using QUIC over UDP. In the next post ill cover about DNS, CDNs, Anycast, REST,GRPC and GraphQL Thanks for reading this post and thank you for your time, repost it it will help a lot reaching and increasing the audience :)

Lets learn about the core fundamentals of Backend Engineering About Authentication and Authorizations. Many of you learned about JWT tokens which is used to implement user authentication and authorisation system. Most of you have never heard about JOSE JSON Object Signing and Encryption before moving into it. Lets what problem it solves. The Problem before JOSE: THe apis and microservices needed a standard way to: Sign data → to verify who sent it Encrypt data → so only the intended receiver can read it Represent claims (user info, metadata) in a compact, URL-safe format Use modern cryptography (RSA, EC, AES, etc.) Transmit tokens across HTTP, URLs, cookies without breaking formatting Before JOSE, developers used custom token formats, mixed crypto libraries, and every system implemented signing/encryption differently → this created: No standard format Interoperability issues Difficult key management Confusing signature/wrapping conventions So now we know the problem lets see what JOSE is: JOSE is a complete package full family of RFCs that define how to securely sign, encrypt, exchange keys, and represent tokens. JOSE Has JWE,JWS,JWT,JWK, JWA: JWS: JSON Web Signature,Standard for signing any payload (not only JWTs). JWE : JSON Web Encryption,Standard for encrypting any payload. JWK :JSON Web Key,Standard way to represent public/private keys in JSON. JWA :JSON Web Algorithms,Defines supported algorithms (RSA, EC, AES, HMAC). JOSE provides a unified, interoperable cryptographic ecosystem by standardizing how data is signed through JWS, encrypted through JWE, and how keys are represented through JWK ensuring secure, consistent, cross language signing, encryption, and verification across systems like Python, Node, Java, and .NET. So basically with JOSE you dont have to do custom token formats and mixed crypto libraries across services it makes the one standarlized way so that i can be used any where without any mess. Thanks for reading :) And share if you liked this short summary of JOSE