DEV Community: Saksham Malhotra

Go Beyond Basics: Closures, Interfaces, and Why Go Has No Inheritance

Saksham Malhotra — Fri, 24 Oct 2025 07:38:02 +0000

I’ve already covered some of the basics of Go earlier. However, before diving into topics like goroutines and wait times, I think it’s important to first discuss a few key aspects of **Go **and how it’s typically used.

Closures

As we already know, Go has closures just like javascript. The only differences are:

Strong typing make closures more predictable.
Go closures capture variables by reference, not by value (similar to using var in JS instead of let or const).

  funcs := []func(){}

    for i := 0; i < 3; i++ {
        funcs = append(funcs, func() {
            fmt.Println(i)
        })
    }

    for _, f := range funcs {
        f()
    }

Stringer

Go has a built-in interface called fmt.Stringer. When you print a value using fmt.Println, fmt.Printf, or similar functions, Go’s formatting code internally checks:

“Does this value implement the Stringer interface?”

If yes then, it calls your custom String() method to get the string representation. Else it prints the default (struct fields, numeric value, etc.).

func (p ProductID) String() string {
    return fmt.Sprintf("Product-%d", p)
}

func main() {
    id := ProductID(42)
    fmt.Println(id) // prints: Product-42
}

Bonus: Go’s Type System Rule - Named types are distinct from their underlying types.

No method overloading

Yes, you heard it right, no more confusion arising from same-name methods. Go’s interface satisfaction is structural and implicit.

It doesn’t care which interface you meant to implement.
It only cares that your type’s method set matches the interface’s method signatures.

So if two interfaces have identical methods, implementing one automatically implements the other.

type A interface {
    String() string
}

type B interface {
    String() string
}

func (a int) String() string{
   return fmt.Sprintf("%d", a)
}

var a A = 7 
a.String()

The above code won’t compile because func (a int) is invalid in Go — you cannot attach a method to an unnamed type.

Corrected version:

type MyInt int

type A interface {
    String() string
}

type B interface {
    String() string
}

func (a MyInt) String() string{
   return fmt.Sprintf("%d", a)
}

var a A = MyInt(7) 
a.String();

Interface values are two-part boxes

A Go interface value is actually a pair of things:
(dynamic type, dynamic value)
Eg:
var a A = MyInt(7)
(dynamic type = MyInt, dynamic value = 7)

Unlike other languages, you’re not “creating an object of the interface”

Instead, you’re creating a variable of interface type that stores a value (of any type) that satisfies the interface.
The interface variable is like a box that can hold any value, as long as the value provides the required methods.

Interface = Plug socket.
Any type that fits (has the right methods) can plug in; no prior agreement required.

Methods Can Belong to Any Named Type

In Go, you can attach a method to any named type, not just structs or interfaces.

type ProductID int

func (p ProductID) String() string {
    return fmt.Sprintf("Product-%d", p)
}

Now, this brings us to a question:

Why do interfaces exist even though any named type can have methods?

And the answer is simple, the methods attached to a type is encapsulation, but not polymorphism.

What methods to a type can't do:

type ProductID int
func (p ProductID) String() string { return fmt.Sprintf("Product-%d", p) }

type OrderID int
func (o OrderID) String() string { return fmt.Sprintf("Order-%d", o) }

type CustomerID int
func (c CustomerID) String() string { return fmt.Sprintf("Customer-%d", c) }

Without any interface, you would need to write one function per type :

func PrintProduct(p ProductID) { fmt.Println(p.String()) }
func PrintOrder(o OrderID) { fmt.Println(o.String()) }
func PrintCustomer(c CustomerID) { fmt.Println(c.String()) }

Interfaces solve this problem:
They say, I don't care about the type as long as it knows how to do this behavior:

type Stringer interface {
    String() string
}

func PrintAnything(s Stringer) {
    fmt.Println(s.String())
}
PrintAnything(ProductID(1))
PrintAnything(OrderID(2))
PrintAnything(CustomerID(3))

Contract not Inheritance

The interface just describes behavior i.e. a contract, not an implementation.

type A interface {
    Foo()
}

type MyType struct{}

func (m MyType) Foo() {
    fmt.Println("Hello from Foo")
}

var a A = MyType{} 
a.Foo()

Above thing works because MyType has a method Foo() with the same signature as required by A. It's not inheritance or anything else, but a contract.
So, if A was :

type A interface{
   Foo()
   Foo2()
}

and rest of the code remain same, then it will be a compiler error, since the interface contract says a to have two methods but a = MyType{} is only assigning it one.

Conclusion

Go’s design favors clarity, not magic. It doesn’t hide behavior behind inheritance or overloading; instead, it gives you small, powerful primitives: named types, methods, and interfaces.

Interfaces in Go aren’t about hierarchy but about capability. If a type can do what’s expected, it fits. That’s why Go’s polymorphism feels lightweight yet expressive.

From closures that behave predictably, to interfaces that define contracts rather than family trees, it reminds us that simplicity, when designed well, is not a limitation but a superpower.

Go Programming Language : Basics

Saksham Malhotra — Thu, 08 May 2025 06:00:56 +0000

Go (or Golang) is a statically typed, compiled programming language made by Google. It's popular for its simplicity, speed, and built-in support for concurrency.

This guide covers Go basics with examples so we can easily come back and revise together.

Let's dive into Go—the language powering the cloud!

Variables and Constants

Go requires you to declare variables with specific types, making sure everything is checked at compile time. You can declare them in different ways, with or without initial values.

func main() {
    // Variable with type inference
    var message = "Hello, Go!"

    // Short variable declaration (inside functions only)
    count := 42

    // Constant declaration
    const PI = 3.14

    // Zero value (false for bool)
    var ready bool

    // Print all values
    fmt.Println(message, count, PI, ready)

    // Explicit type conversion (int to float64)
    fmt.Println("Type conversion:", float64(count)/7)
}

Key points

Variables always have a default _"zero" value: 0, "", false, or nil _(for pointers, slices, maps, etc.).
Constants are fixed values set at compile time. They can only be numbers, strings, or booleans.
Go _doesn't do automatic type conversion. _You must convert types explicitly using Type(value) to avoid hidden bugs.

Control Structures

Go provides familiar control structures with clean, minimal syntax.

A key design choice is that Go requires curly braces {} even for single-line blocks, but does not require parentheses () around conditions.

Simple `for` loop

for i := 0; i < 3; i++ {  
     fmt.Println("Iteration:", i)  
}

`for` loop used as a `while` loop

counter := 0  
for counter < 3 {  
    fmt.Println("Counter:", counter)  
    counter++  
 }

Infinite loop with `break`

sum := 0  
for {  
    sum++  
    if sum > 3 {  
        break  
    }  
    fmt.Println("Sum:", sum)  
}

`if-else` statement with inline initialization

if grade := 85; grade >= 70 {  
    fmt.Println("You passed with a grade of", grade)  
} else if grade >= 60 {  
     fmt.Println("You barely passed with a grade of", grade)  
} else {  
     fmt.Println("You failed with a grade of", grade)  
}

`switch` statement

role := "admin"  
switch role {  
case "guest":  
    fmt.Println("Limited access granted")  
case "user":  
    fmt.Println("Standard access granted")  
case "admin":  
    fmt.Println("Full access granted")  
default:  
    fmt.Println("No access")  
}

`switch` with `time.Weekday()`

switch time.Now().Weekday() {  
case time.Saturday, time.Sunday:  
    fmt.Println("It's the weekend!")  
default:  
    fmt.Println("It's a weekday.")  
}

Key Points

for is the only loop in Go — but it's flexible enough to act like a C-style for, while, or an infinite loop.
if can include setup code before the condition — great for things like error checks.
switch is powerful and clean:
- No fallthrough by default (no break needed).
- Cases can be expressions, not just constants.
- One case can match multiple values.
- switch without an expression means switch true.
Go supports goto, but use it only when absolutely needed (like breaking out of nested loops).

Data Structures: Arrays and Slices

Go has built-in data structures like arrays and slices.

An array is a fixed-size collection of elements all of the same type, and its size is part of its type — so you can’t resize it.
A slice is a more flexible, resizable version of an array, and it's the most commonly used sequence type in Go.

Do slices in Go have different types of elements?

No, slices in Go must contain elements of the same type. If you need mixed types, you can use a slice of empty interfaces ([]interface{}),

but that's generally avoided unless truly needed.

Arrays

Declared as: var scores [4]int
Assigned as: scores[0] = 32
Initialized with values: grades := [3]int{98, 93, 87}
Letting the compiler count elements: colors := [...]string{"red", "green", "blue"}

Slices

Declared as: var names []string
Assigned with values: names = []string{"Alice", "Bob"}
Initialized directly: primes := []int{2, 3, 5, 7}
Using ... is not allowed in slice literals (only in arrays)
Appending to a slice:
- Single: names = append(names, "Charlie")
- Multiple: numbers = append(numbers, 4, 5)
Slice from an array:

  arr := [5]int{10, 20, 30, 40, 50}
  slice := arr[1:4] // [20 30 40]

Key Points

Arrays in Go are value types — not pointers like in some other languages.
Assigning an array or passing it to a function results in a full copy of the array.
Slices hold a reference to the underlying array. Copying a slice points to the same data.
The append function may create a new underlying array if capacity is exceeded.
Slicing (e.g., s[1:4]) creates a new slice pointing to the same array, so changes affect the original.
The zero value of a slice is nil, with 0 length and 0 capacity.

Data structures: Maps

Maps in Go are the equivalent of hash tables or dictionaries in other languages. They provide an unordered collection of key-value pairs, where each key is unique.

Nil map

// Nil map
var empty map[string]int
fmt.Println("Empty map:", empty, "Nil?", empty == nil)

Creating and adding data to a map

// Map with make and adding data
scores := make(map[string]int)
scores["Alice"], scores["Bob"], scores["Charlie"] = 92, 85, 79
fmt.Println("Scores:", scores)

Map literal

// Literal map
pop := map[string]int{"New York": 8419000, "Los Angeles": 3980000, "Chicago": 2716000}
fmt.Println("Population:", pop)

Access with existence check

// Access with check
if score, ok := scores["Bob"]; ok {
    fmt.Println("Bob's score:", score)
} else {
    fmt.Println("Bob's score not found")
}

Delete a key

// Delete a key
delete(scores, "Charlie")
fmt.Println("After deletion:", scores)

Iterating over a map

// Iterate map
fmt.Println("City populations:")
for city, p := range pop {
    fmt.Printf("%s: %d\n", city, p)
}

Comparing maps

// Compare maps
c1 := map[string]int{"New York": 8419000, "Los Angeles": 3980000}
c2 := map[string]int{"Los Angeles": 3980000, "New York": 8419000}
fmt.Println("Maps equal?", maps.Equal(c1, c2))

Key points

Maps are reference types; modifying one variable affects all references.
The zero value of a map is nil. A nil map causes a runtime panic when adding keys.
Map lookups return two values: the value and a boolean for existence.

  value, ok := myMap[key]

The order of iteration over a map is not guaranteed and can change between executions.

Functions

Functions are first-class citizens in Go. They can be passed as arguments, returned from other functions, and assigned to variables. Go functions can return multiple values, making error handling more explicit.

Basic Call


func greet(name string) string {
    return "Hello, " + name
}
greeting := greet("Alice")

Multiple Return Values with Error Handling

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, fmt.Errorf("cannot divide by zero")
    }
    return a / b, nil
}
// Inside main function
result, err := divide(10, 2)
if err != nil {
    fmt.Println(err)
} else {
    fmt.Println("Result:", result)
}

Named return values

// Function Definition
func calculate(a, b int) (sum, diff int) {
    sum = a + b
    diff = a - b
    return
}
// Inside main function
s, d := calculate(5, 3)

Variadic functions

// Function Definition
func sum(values ...int) int {
    total := 0
    for _, v := range values {
        total += v
    }
    return total
}
// Inside main function
result := sum(1, 2, 3, 4)

Higher-order function

func applyOperation(a, b int, op func(int, int) int) int {
    return op(a, b)
}
// Inside main function
add := func(x, y int) int { return x + y }
result := applyOperation(5, 3, add)

Key points

Multiple Return Values: Enables cleaner error handling patterns. The convention is to return the error as the last value.
Named Return Values: Parameters in the return type can be named and used as variables within the function, improving readability, especially for complex functions.
Variadic Functions: The ... syntax allows a function to accept any number of arguments of a specified type. These arguments are received as a slice inside the function.
Functions as First-Class Citizens: Functions can be:
- Assigned to variables
- Passed as arguments
- Returned from other functions
- Stored in data structures
Closures: Go supports anonymous functions and closures, which can access variables from their enclosing scope even after that scope has finished executing.
Defer Statement: The defer keyword schedules a function call to be executed just before the function returns, useful for cleanup operations.

Closures and Pointers

Closures are anonymous functions that can reference variables from the function in which they are defined. Pointers in Go hold the memory address of a value, allowing you to share data across your program without copying it.

Closures

// Function Definition for Closure
func closureExample() func() int {
    x := 10
    return func() int {
        return x
    }
}
// Inside main function
closure := closureExample()
fmt.Println(closure()) // Outputs 10

Pointers

// Function Definition for Pointers
func incrementValue(p *int) {
    *p += 1
}
// Inside main function
value := 5
incrementValue(&value)
fmt.Println(value) // Outputs 6

Structs and Custom Types

Structs in Go are collections of fields, similar to classes in other languages but without inheritance. Go also allows you to create custom types based on existing types, with methods as well.

Custom type & method for it

type UserID int 
func (id UserID) Str() string {
   return fmt.Println(id)
}

var userId UserID = 42 
fmt.Println("User ID:", userID) 
fmt.Println("Formatted ID:", userID.String())

Basic struct definition & Methods

type Product struct {
    ID        int
    Name      string
    Price     float64
    CreatedAt time.Time
}

func NewProduct(id int, name string, price float64) *Product {
    return &Product{
        ID:        id,
        Name:      name,
        Price:     price,
        CreatedAt: time.Now(),
    }
}

func (p Product) PriceWithTax(taxRate float64) float64 {
    return p.Price * (1 + taxRate)
}

func (p *Product) ApplyDiscount(percent float64) {
    p.Price = p.Price * (1 - percent/100)
}

NewProduct is a constructor function for the Product struct. It initializes a new Product instance with the given values and sets the CreatedAt field to the current time using time.Now().

The Product struct also has two methods:

-** PriceWithTax :** This is a value receiver method, meaning it works on a copy of the Product instance. It_ does not modify the original Product_. It calculates and returns the price after applying a tax rate, but leaves the original Price unchanged.

ApplyDiscount : This is a pointer receiver method, meaning it works on the actual Product instance and can modify its fields. It applies a discount percentage directly to the Price field, reducing it in place.

Embedded struct

type InventoryItem struct {
    Product  // Embedded struct (anonymous field)
    Quantity int
    Location string
}

It means that the InventoryItem struct embeds another struct, Product, without giving it a field name — this is called embedding an anonymous field in Go.

Creating a var of struct

laptop := Product{
    ID:        1,
    Name:      "Laptop",
    Price:     999.99,
    CreatedAt: time.Now(),
}
fmt.Println("Product:", laptop)
fmt.Println("Laptop name:", laptop.Name)
fmt.Println("Laptop price:", laptop.Price)

Key Points

Value Semantics: Structs are value types—assign or pass them, and you get a copy.
Constructor Functions: Go doesn’t have built-in constructors, but you can make functions like NewType() to create structs.
Method Receivers: Methods use value receivers (copy) or pointer receivers (can change original).
Embedding: Go has no inheritance. Use embedding to include another struct directly—fields and methods are promoted.
Method Attachment: You can attach methods to any type, not just structs—as long as the type is defined in the same package.

Example:

type UserID int

func (id UserID) String() string {
    return fmt.Println(id)
}

var id UserID = 42
id.String() -> correct

Interfaces

Interfaces in Go define a set of method signatures. A type implements an interface by implementing its methods. Unlike many other languages, interface implementation is implicit in Go-there's no _"implements" _keyword.

Define an interface

type Greeter interface {
    Greet() string
}

Independent types

// English type
type English struct{}

func (e English) Greet() string {
    return "Hello!"
}

// Spanish type
type Spanish struct{}

func (s Spanish) Greet() string {
    return "Hola!"
}

Use of interfaces with types

// Function that accepts interface
func SayGreeting(g Greeter) {
    fmt.Println(g.Greet())
}

func main() {
    eng := English{}
    esp := Spanish{}

    SayGreeting(eng) // Output: Hello!
    SayGreeting(esp) // Output: ¡Hola!
}

Key points

Interfaces in Go make code flexible and loosely connected.
Go types don’t need to declare they implement an interface — if they have the required methods, they do.
The empty interface interface{} (or any in Go 1.18+) has no methods, so all types implement it. Useful for unknown types.
Go encourages small, focused interfaces — often with just one or two methods.

Important points

var w io.Writer       // `w` is an interface variable of type Writer
w = os.Stdout         // Assign a concrete value of type *os.File to it
w.Write([]byte("Hello"))  // Call the Write method through the interface

io.Writer is an interface that has a method Write([]byte) (int, error)
os.Stdout is a concrete value of type *os.File, which implements the io.Writer interface.
So w now holds the type *os.File and its value (os.Stdout).
You can call w.Write(...) even though you don’t know the exact type at compile time — that’s polymorphism.

Enums

Go doesn't have a dedicated enum type like some other languages, but it provides a pattern using constants and the iota identifier to create enumerated types.

type Month int

const (
    January Month = iota + 1 // Start with 1 instead of 0
    February
    March
    April
)

type Color string

const (
    Red    Color = "RED"
    Green  Color = "GREEN"
    Blue   Color = "BLUE"
)

//usage 
    var color Color = Blue

iota is reset to 0 whenever the const keyword appears and increments by 1 for each constant in a block.

Generics

Generics in Go allow you to write functions and data structures that operate on values of any type, while still maintaining type safety. They're particularly useful for implementing reusable algorithms and data structures.

Generic function with a type parameter

func PrintItems[T any](items []T) {
    fmt.Println("Items contents:")
    for i, item := range items {
        fmt.Printf("[%d]: %v\n", i, item)
    }
}

Using interface for constraints

type Numeric interface {
    int | int8 | int16 | int32 | int64 | float32 | float64
}

func Sum[T Numeric](values []T) T {
    var sum T
    for _, v := range values {
        sum += v
    }
    return sum
}

Conclusion

Go is a powerful yet simple language that offers a strict type system, slices, pointers, generics, and interfaces with implicit inheritance.

In the next section, I'll discuss goroutines, wait times, and other related topics, covering the remaining features of Go.

"Designing Data-Intensive Applications": Chapter 2 - Graph like Data Models and Query Languages - Part III

Saksham Malhotra — Sun, 04 May 2025 15:11:33 +0000

Welcome back to the third part of our dive into Chapter 2 of Designing Data-Intensive Applications. In the previous sections, we explored how document and relational databases handle various data relationships. Now, we’ll explore graph-like data models—particularly useful for modeling complex, interconnected data—and their query languages: Cypher, SQL (recursive), and SPARQL.

Graph‑Like Data Models

When you start modeling data, relationships are everything:

One‑to‑many → Document model
Many‑to‑many → Relational model
Complex many‑to‑many → Graph model

Graphs shine when the connections themselves carry meaning.

But wait, what is a Graph? 🤔

A graph is made of:

Vertices (nodes or entities)
Edges (relationships or arcs) Examples:
Social graph: vertices = people, edges = friendships
Web graph: vertices = pages, edges = hyperlinks
Road network: vertices = intersections, edges = roads

Even better—graphs can hold heterogeneous data in one store!

Facebook’s graph includes people, locations, events, check‑ins, comments…

Edges capture friendships, check‑in locations, comments-on-posts, event attendance, and more.

Taking an example

Imagine two people:

Lucy (from Idaho, USA)
Alain (from Beaune, France)

They’re married and live in London.

A graph can capture:

Lucy
- born in → Idaho
- lives in → London
Alain
- born in → Beaune
- lives in → London
Idaho within → USA
Beaune within → France
London within → England → Europe

You could imagine extending the graph to also include many other facts about Lucy and Alain, or other people. For instance, you could use it to indicate any food allergies they have.

Evolvability, that's what graphs provide us.

Property Graph Model

Vertices have:

Unique ID
Incoming & outgoing edge lists
Properties (key–value pairs)

Edges have:

Unique ID
Tail vertex (start)
Head vertex (end)
Label (relationship type)
Properties (key–value pairs)

Under the hood, you can imagine two tables:

CREATE TABLE vertices (
  vertex_id INTEGER PRIMARY KEY,
  properties JSON
);
CREATE TABLE edges (
  edge_id    INTEGER PRIMARY KEY,
  tail_vertex INTEGER REFERENCES vertices(vertex_id),
  head_vertex INTEGER REFERENCES vertices(vertex_id),
  label       TEXT,
  properties  JSON
);
CREATE INDEX edges_tails ON edges(tail_vertex);
CREATE INDEX edges_heads ON edges(head_vertex);

This gives you fast lookups of incoming/outgoing edges and lets you mix any labels you like—all in one graph!

Important aspects of this model include :

Any vertex can have an edge with any other vertex. No schema restricts which kinds of thing can or cannot be associated
Given any vertex, you can definitely, find both it's incoming and outgoing edges, leading to any path.
By using labels for different relationships, you can store several different kind of info in a single graph, while maintaining a clear data model.

Cypher Query Language

Cypher is a declarative query language for property graphs, created for the Neo4j
graph database.
It works in the following manner :

CREATE
  (NAmerica:Location {name:'North America', type:'continent'}),
  (USA:Location      {name:'United States', type:'country'}),
  (Idaho:Location    {name:'Idaho', type:'state'}),
  (Lucy:Person       {name:'Lucy'}),
  (Idaho)-[:WITHIN]->(USA)-[:WITHIN]->(NAmerica),
  (Lucy)-[:BORN_IN]->(Idaho);

The same arrow notation is used in a MATCH clause to find patterns in the graph.
Eg: Cypher query to find people who emigrated from the US to Europe

MATCH
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
(person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name

[:WITHIN*0..] means “follow 0 or more WITHIN edges”

The query can be read as follows:
Find any vertex (call it person) that meets both of the following conditions:

Person has an outgoing BORN_IN edge to some vertex. From that vertex, you can follow a chain of outgoing WITHIN edges until eventually you reach a vertex of type Location, whose name property is equal to "United States".
That same person vertex also has an outgoing LIVES_IN edge. Following that edge, and then a chain of outgoing WITHIN edges, you eventually reach a vertex of type Location, whose name property is equal to "Europe".

Hence, with cypher, graphs has become more advantageous over relational DB for more complex and evolving, schemas that involve interesting many-to-many relations.

SQL with Recursive CTEs

This SQL query demonstrates the use of recursive Common Table Expressions (CTEs) to navigate hierarchical graph data stored in a relational database. It models entities like countries, continents, and people as vertices, and relationships such as "within", "born_in", and "lives_in" as directed edges. The goal is to identify individuals who were born in the United States and currently live in Europe.

The recursive CTEs in_usa and in_europe traverse the "within" hierarchy to build complete sets of locations within the U.S. and Europe, respectively.
Subsequent CTEs then use these sets to filter people based on their "born_in" and "lives_in" relationships.

WITH RECURSIVE
  in_usa(vertex_id) AS (
    SELECT vertex_id FROM vertices WHERE properties->>'name'='United States'
    UNION
    SELECT e.tail_vertex
      FROM edges e JOIN in_usa u ON e.head_vertex=u.vertex_id
     WHERE e.label='within'
  ),
  in_europe(vertex_id) AS (
    SELECT vertex_id FROM vertices WHERE properties->>'name'='Europe'
    UNION
    SELECT e.tail_vertex
      FROM edges e JOIN in_europe eu ON e.head_vertex=eu.vertex_id
     WHERE e.label='within'
  ),
  born_in_usa AS (
    SELECT tail_vertex AS vertex_id
      FROM edges JOIN in_usa ON edges.head_vertex=in_usa.vertex_id
     WHERE edges.label='born_in'
  ),
  lives_in_europe AS (
    SELECT tail_vertex AS vertex_id
      FROM edges JOIN in_europe ON edges.head_vertex=in_europe.vertex_id
     WHERE edges.label='lives_in'
  )
SELECT v.properties->>'name'
  FROM vertices v
  JOIN born_in_usa  b ON v.vertex_id=b.vertex_id
  JOIN lives_in_europe l ON v.vertex_id=l.vertex_id;

That's 29 lines vs. 4 lines for the same job!

Use appropriate DB for your Application

Triple Stores & SPARQL

The triple-store model is mostly equivalent to the property graph model, using different words to describe the same ideas.
In a Triple store, all information is stored in the form of very simple three-part statements: (subject, predicate, object):

_Predicate_s are either properties or edges
Objects can be literals (strings, numbers) or other vertices

The subject of a triple is equivalent to a vertex in a graph. The object is one of two things:

A value in a primitive datatype, such as a string or a number. In that case, the predicate and object of the triple are equivalent to the key and value of a property on the subject vertex. For example, (lucy, age, 33) is like a vertex lucy with properties {"age":33}.
Another vertex in the graph. In that case, the predicate is an edge in the graph, the subject is the tail vertex, and the object is the head vertex. For example, in (lucy, marriedTo, alain) the subject and object lucy and alain are both vertices, and the predicate marriedTo is the label of the edge that connects them.

Turtle (N3) example:

@prefix : <urn:example:>.

_:lucy a        :Person;
       :name    "Lucy";
       :bornIn  _:idaho.

_:idaho a       :Location;
       :name    "Idaho";
       :type    "state";
       :within  _:usa.

_:usa a         :Location;
       :name    "United States";
       :type    "country";
       :within  _:namerica.

_:namerica a    :Location;
       :name    "North America";
       :type    "continent".

In this example, vertices of the graph are written as _:someName. The name doesn’t mean anything outside of this file; it exists only because we otherwise wouldn’t know which triples refer to the same vertex. When the predicate represents an edge, the object is a vertex, as in _:idaho :within _:usa. When the predicate is a property, the object is a string literal, as in _:usa :name "United States".

Semantic Web

Semantic Web
Think of the web as a huge neighborhood where every house can share its address book. RDF (Resource Description Framework) was meant to give each site a common “address label” so computers could easily swap and connect data.

Triple stores are the filing cabinets that hold all those address cards—simple databases of (subject, predicate, object) facts.
The Semantic Web is the big idea of using those linked facts across the entire internet, so apps can mix and match data from any site.

Sadly, it never became the norm. Too many complicated rules and acronyms scared people off, so most sites stayed with plain HTML. The idea was clever—it just didn’t catch on.

Conclusion 🎯

Graph‑like models unlock a whole new way to think about data—one where the relationships are just as important as the entities themselves. We’ve seen how:

Document and relational databases cover one‑to‑many and many‑to‑many cases well
Graphs step in when those relationships get really intricate or start changing over time
Cypher, recursive SQL, and SPARQL each shine in expressiveness for different graph flavors
Triple stores package facts as simple (subject, predicate, object) entries
The Semantic Web dream of a global, machine‑readable web was bold, if not quite reality

As you design your next data‑heavy app, think about which model fits your use case:

Lots of nested documents? Go document-store.
Predictable joins? Relational is solid.
Dynamic, evolving networks? Graphs are your friend.

Stay tuned for Part IV, where we’ll dive into Datalog, RDF, and more tools for wrangling connected data!

Chapter 2: Designing Data-Intensive Applications - Data models - Part 2 : Query Languages

Saksham Malhotra — Thu, 01 May 2025 06:30:36 +0000

In the first part of this chapter, we discussed relational databases and NoSQL systems. Now, let’s look at something fundamental to how we interact with data: query languages. This introduces the differences between declarative and imperative approaches, their applications in web development, and even how distributed systems like MapReduce fit into this picture.

Declarative vs. Imperative Querying

When relational databases were introduced, they didn’t just offer a new way of storing data—they introduced a simpler way of querying it. SQL became the standard, and it’s a declarative query language, unlike earlier systems like IMS and CODASYL, which used imperative code.

What’s the Difference?

Here’s an example of imperative code in JavaScript to find all sharks in a dataset:

function getSharks() {
  var sharks = [];
  for (var i = 0; i < animals.length; i++) {
    if (animals[i].family === "Sharks") {
      sharks.push(animals[i]);
    }
  }
  return sharks;
}

Step by step, you’re telling the computer how to do it: loop through the data, check a condition, and store the result.

Now look at the declarative version:

SELECT * FROM animals WHERE family = 'Sharks';

You just specify what you want—“Give me all animals where the family is Sharks”—and let the database figure out how to get it.

Why Declarative Wins

Simplicity: Declarative languages let you focus on the result, not the process.
Optimization: The database can optimize how it executes the query (e.g., using indexes or parallel processing).
Parallel Execution: Declarative code doesn’t rely on strict execution order, making it easier to run across multiple cores or machines.

Declarative Queries on the Web

This difference isn’t just for databases—it’s everywhere, including web development. Let’s take a simple example:

<ul>
  <li class="selected">
    <p>Sharks</p>
    <ul>
      <li>Great White Shark</li>
      <li>Tiger Shark</li>
      <li>Hammerhead Shark</li>
    </ul>
  </li>
  <li>
    <p>Whales</p>
    <ul>
      <li>Blue Whale</li>
      <li>Humpback Whale</li>
      <li>Fin Whale</li>
    </ul>
  </li>
</ul>

You want to highlight the <p> element of the selected <li> with a blue background. In CSS (declarative), you’d write:

li.selected > p {
  background-color: blue;
}

This selector simply declares the pattern of elements to style.

In contrast, here’s an imperative JavaScript version:

var liElements = document.getElementsByTagName("li");
for (var i = 0; i < liElements.length; i++) {
  if (liElements[i].className === "selected") {
    var children = liElements[i].childNodes;
    for (var j = 0; j < children.length; j++) {
      var child = children[j];
      if (child.nodeType === Node.ELEMENT_NODE && child.tagName === "P") {
        child.setAttribute("style", "background-color: blue");
      }
    }
  }
}

Why Declarative is Better

Cleaner Code: The CSS snippet is shorter and easier to understand.
Dynamic Updates: If the selected class changes dynamically, CSS handles it automatically, but the JavaScript version would require extra work.

MapReduce Querying

So far, we’ve talked about declarative vs. imperative approaches in databases and web development. Let’s now look at distributed systems, starting with MapReduce.

MapReduce is a programming model popularized by Google for processing large datasets across many machines. It’s not fully declarative or imperative—it’s somewhere in between.

Example Use Case

Say you’re a marine biologist tracking animal sightings. You want a report showing the number of sharks observed per month.

In PostgreSQL, you’d write:

SELECT date_trunc('month', observation_timestamp) AS observation_month,
       sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks'
GROUP BY observation_month;

In MongoDB’s MapReduce, it looks like this:

db.observations.mapReduce(
  function map() {
    var year = this.observationTimestamp.getFullYear();
    var month = this.observationTimestamp.getMonth() + 1;
    emit(year + "-" + month, this.numAnimals);
  },
  function reduce(key, values) {
    return Array.sum(values);
  },
  {
    query: { family: "Sharks" },
    out: "monthlySharkReport"
  }
);

Here’s what’s happening:

Map Function: Processes each document, emitting key-value pairs like "2025-05" and numAnimals.
Reduce Function: Groups data by keys (e.g., months) and performs calculations (e.g., summing up observations).

Pros and Cons

Flexibility: The Map and Reduce functions can include custom logic.
Complexity: Writing two coordinated functions is harder than a single declarative query.

Aggregation Pipelines

Recognizing the complexity of MapReduce, MongoDB introduced the aggregation pipeline in version 2.2. This is a declarative query language with a JSON-based syntax.

Here’s how our shark observation query would look:

db.observations.aggregate([
  { $match: { family: "Sharks" } },
  { $group: {
      _id: {
        year: { $year: "$observationTimestamp" },
        month: { $month: "$observationTimestamp" }
      },
      totalAnimals: { $sum: "$numAnimals" }
    }
  }
]);

The aggregation pipeline is simpler and easier to use than MapReduce while still being powerful.

Takeaways

Declarative Query Languages: Abstract away the "how," making them easier to write and optimize.
Imperative Code: Useful in some cases but often verbose and harder to maintain.
MapReduce: A hybrid approach, powerful but more complex than declarative alternatives.
Aggregation Pipelines: Offer a declarative, user-friendly alternative to MapReduce for distributed querying.

Declarative querying isn’t just about writing less code—it’s about making systems smarter, more efficient, and easier to maintain. In the next chapter, we’ll continue exploring the tools and patterns that make modern data systems tick.

Conclusion

Understanding the distinction between declarative and imperative query languages is crucial for designing scalable and maintainable systems. Declarative approaches, like SQL and aggregation pipelines, allow for cleaner, more optimized queries that abstract away complexity—making them ideal for modern, data-intensive applications. Meanwhile, imperative models still have their place when fine-grained control or custom logic is needed, especially in distributed systems. Striking the right balance is key to building robust architectures.

"Designing Data-Intensive Applications": Chapter 2 - Data Models - Part I

Saksham Malhotra — Sat, 26 Apr 2025 13:11:56 +0000

"Bad programmers focus too much on writing code. Great programmers care more about how data is organized and connected."

Let’s be honest: We’ve all picked a database just because it was popular. But here’s the truth—your data model isn’t just a place to store stuff. It’s the backbone of your app. If you get it wrong, you’ll be stuck patching things up late into the night. Don’t worry—we’re in this together.

🕰️ A Quick Look Back at Data Chaos

The Rise of Relational Databases (1970s–Present)

Relational databases have become the foundation of modern data management—trusted, familiar, and widely adopted.

Tables and Rows: Structured like spreadsheets, but far more powerful and flexible.
SQL: The standard query language that introduced concepts like "WHERE" to everyday development.
Everyday Impact: Powers critical systems, from banking ATMs to dating applications.

Why it became the standard:

✔️ Simple and intuitive data structure

✔️ Reliable ACID transactions ensuring data integrity

✔️ A proven, dependable choice for developers across industries

The following is an image representing the LinkedIn profile of Bill Gates using a relational schema.

Other Early Database Models

Before SQL and relational databases became dominant, several other database models tried to address data management challenges:

Database Model	Strengths	Limitations	Legacy
Hierarchical (IMS)	Extremely fast for early computing needs	Struggled with handling complex relationships	Influenced the design of document databases
Network (CODASYL)	Allowed flexible and rich connections	Difficult to design and maintain	Highlighted the drawbacks of overly complex linking
Object-Oriented	Modeled data closely to object-oriented programming	Not always well-suited for database requirements	Inspired object-relational mapping (ORM) tools
XML Databases	Human-readable format	Became cumbersome and difficult to manage at scale	Left a legacy in early web services and data interchange formats

The NoSQL Revolution: Moving Beyond Traditional Tables

By the 2010s, the limitations of rigid, predefined table structures became more apparent, especially with the rise of large-scale web applications. Developers began exploring more flexible ways to store and retrieve data.

Document Databases (e.g., MongoDB, CouchDB):

Flexible Structure: Schemas are dynamic, allowing the data model to evolve over time.
Nested Data: Supports hierarchical data storage, similar to embedded structures like JSON.
High Performance for Simple Queries: Optimized for rapid retrieval of documents, though complex relationships across documents can be more challenging to manage.

Real-World Use Case:

// Perfect for that "move fast and break things" phase
{
  "startup_phase": "pre-revenue",
  "tech_stack": ["Blockchain", "AI", "NFT"],
  "burn_rate": "$100k/month",
  "exit_strategy": "Acquired by Google (please)"
}

This shift increased the one-to-many relationships in the data. Each JSON document with one-to-many relationships started to look like this :

The Great Debate: Relational vs. Document Databases

When Document Databases Are a Better Fit:

Your data is naturally nested, resembling hierarchical structures (like nested folders or Matryoshka dolls).
You prefer flexibility, avoiding the need to constantly update a fixed database schema.
Your application's main task is to retrieve and display entire records or related data at once.

When Relational Databases Excel:

Your data is highly interconnected, requiring complex relationships (similar to a social network where everyone is connected).
You need to perform detailed queries that combine and filter data across multiple entities ("Find all customers who purchased a product and live in a specific region").
You require strict consistency and integrity of your data, ensuring reliable and accurate transactions.

Scenario	Document Database Advantage	Relational Database Advantage
Blog posts with comments	Simple single-document model	Requires multiple tables and joins
Banking system	Difficult to ensure consistency	Supports atomic, reliable transactions
Social network	Challenging to model complex relationships	Handles graph-like, interconnected queries effectively

This is one of the key reasons why relational databases are typically preferred over document databases when managing many-to-many relationships.

Mixing Approaches: Combining the Best of Both Database Styles

Modern databases are evolving, blending the strengths of both relational and document models:

PostgreSQL: Primarily a relational database, but now offers powerful support for flexible JSON data types, allowing for hybrid structured and semi-structured storage.
MongoDB: Originally focused on document storage, it has introduced robust transaction support to ensure greater reliability and consistency.
Google Spanner: Designed to offer the best of both worlds—combining relational structure with horizontal scalability, and enabling global, distributed consistency.

-- Yes, this actually works in modern PostgreSQL
SELECT users->'profile'->>'twitter_handle'
FROM hybrid_db
JOIN social_graph ON (users->>'id' = social_graph->>'user_id')
WHERE transactions->'amount' > 1000;

Key Considerations When Choosing a Database

Will your data remain understandable if your organizational needs change over time?

Document databases offer flexibility for evolving data models, whereas relational databases may require significant restructuring.
How interconnected is your data?

Highly linked data often benefits from relational models, while more independent records can thrive in document-based systems.
Who defines the structure of your data—the application or the database?

This decision greatly impacts how you design, scale, and maintain your system.

Conclusion

Balancing the Best Tools for the Job

The key takeaway today? Using different types of databases for different purposes—like a chef selecting the right tool for each ingredient:

Relational: The reliable, versatile tool for structured data.
Document: The flexible choice for handling nested or evolving data.
Graph: A specialized tool for complex, interconnected data.

Pro Tip:

"Choose your databases as carefully as you choose your shoes—what works for hiking won't work for ballet.

Now, take a step back and plan your data strategy... maybe sketch out your ideas first? 🎨

Cristiano Ronaldo vs. You with 10 Followers - X / Twitter

Saksham Malhotra — Tue, 22 Apr 2025 18:32:12 +0000

Welcome back! In my last post, we explored the three pillars of data systems: reliability, scalability, and maintainability.
You can visit the last chapter from here :
Chapter 1: Foundations of data systems

Today, we'll zoom in on one of the trickiest challenges modern social networks face—fan-out—using Twitter as our case study.

"When Cristiano Ronaldo tweets, it needs to reach 100 million in seconds"

What Is Fan-Out?

Fan-out is the process of delivering one message (a tweet) to all of a user's followers.

If you have 50 followers, fan-out is easy
If you have 100 million followers, you need special magic

There are two main approaches:

Fan-Out on Write
Fan-Out on Read

Approach 1: Fan-Out on Write

(Ideal for "regular" users)

User posts a tweet
The tweet is stored in a durable Tweet Store
A background job pushes that tweet into each follower's Timeline Cache

Read path

When a follower opens Twitter, their timeline is already pre-filled
The app just fetches cached tweets—instant display

Why it works

Fast reads for followers
Simple ranking and pagination

The Scaling Challenge

Let's break down why this fails for celebrities:

# For 31M followers with 90s delivery SLA
31,000,000 followers / 90 seconds = 344,444 writes/sec

# If 1% of followers check immediately
31,000,000 × 1% = 310,000 reads/sec

And there are more than 4.6k writes/sec system-wide. Now imagine if Ronaldo just dropped a 'hello' on X

Trade-offs

Write amplification: N writes per tweet (where N = number of followers)
Doesn't scale to celebrity levels

Approach 2: Fan-Out on Read

(Necessary for mega-stars like Ronaldo)

Celebrity posts a tweet
Store the tweet once in the tweets table
When each follower loads their timeline:
- Fetch their personal cache (small fan-out of regular users)
- Dynamically merge the celebrity's tweet on the fly

SELECT t.id,
       u.screen_name,
       t.text,
       t.timestamp
FROM follows f
JOIN tweets t
  ON t.sender_id = f.followee_id
JOIN users u
  ON u.id = t.sender_id
WHERE f.follower_id = :current_user
ORDER BY t.timestamp DESC
LIMIT 50;

Why it's needed

1 write per tweet—constant cost
Handles millions of followers without crashing

Trade-offs

Slower reads (joins and lookups)
Harder to cache consistently

Twitter's Hybrid Solution

Twitter combines both strategies:

Regular users → Fan-Out on Write
Celebrities → Fan-Out on Read

The Nuanced Reality

Even celebrity tweets use strategic writes for critical followers:

First 1M Followers
- Immediate fan-out-on-write to timeline caches
- Targets super-fans most likely to engage immediately
Remaining Followers
- True fan-out-on-read via dynamic query merging
- Served through geographically distributed edge caches

# Why this hybrid works
100M followers = 
1M (1%) active immediately + 99M (99%) eventual consistency

Core components under the hood:

Tweet Store: Manhattan (Twitter’s distributed database)
Timeline Cache: Redis with active replication
Stream Processing: Heron for batched background jobs
Rate Limiters: Raven for traffic shaping

Key Lessons for Your Own Systems

1. Segment Users by Follower Count

Why:

<10k followers: Full fan-out-on-write is safe and fast
10k-1M followers: Hybrid approach with write batching
>1M followers: Primarily fan-out-on-read with edge caching

2. Precompute vs Compute-on-Demand

Balance:

Precompute: Timeline caches, trending lists, follower graphs
Compute live: Celebrity tweets, search results, archived content

Rule of Thumb:

"Cache what 80% of users will see immediately. Compute what 20% might request later."

3. 99th-Percentile Latency Focus

Why It Matters:

Average latency hides worst-case scenarios
1% slow requests = 3.6M unhappy users/hour (at 100k RPS)

Prioritization:

Ensure 95% requests complete in <100ms
Optimize until 99% <200ms
Let 1% (edge cases) degrade gracefully

4. Hot/Warm/Cold Data:

Hot: In-memory cache (last 3h tweets)
Warm: SSD storage (3h-7d tweets)
Cold: HDD/tape (archival)

"There are no solutions, only trade-offs. The art is balancing write costs vs read complexity."

What's Next?

In the next post, I'll dive into data modeling and query languages—because fast fan-out needs a solid home for your data.

Got fan-out horror stories? Or clever caching tricks? Share them in the comments below! 🚀

"Designing Data-Intensive Applications": Chapter 1 - Foundations of Data Systems

Saksham Malhotra — Fri, 18 Apr 2025 08:31:57 +0000

Welcome to the very first chapter of my epic adventure through Designing Data-Intensive Applications by Martin Kleppmann. Some call it the Bible of System Design. As for me, I call it my new good friend (sorry, coffee mug, you're now replaced).

If you're a software engineer like me—curious, sometimes overwhelmed, and always ready for a good meme—you're in the right place. I'll be sharing what I learn, chapter by chapter, in language that's more "hanging out at a coffee shop" and less "I have a PhD in distributed systems." Let's get into Chapter 1: Reliable, Scalable, and Maintainable Applications. And yes, there will be bad jokes.

Why Am I Reading This Book? (And Maybe You Should Too)

Let's face it: today's apps are less about flexing CPU power and more about wrestling with mountains of data—think Netflix recommendations, petabytes of dog videos, and those wild "You May Also Like" algorithms. The bottleneck isn't usually the CPU—it's the data: how much there is, how messy it gets, and how fast it changes.

This book promises not just to tell us what to do, but how to think about building systems that handle all this data without falling over and making us cry (or worse, making our users cry). Whether you're a newbie or a seasoned sysadmin with battle scars, this book is for anyone who's ever had a system go down at 2am and thought, "There must be a better way."

Chapter 1: The Three Pillars of Data Systems (a.k.a. The Holy Trinity)

Martin says that every robust data system stands on three pillars: reliability, scalability, and maintainability. If you're missing even one, your project is basically a Jenga tower at a toddler's birthday party.

But first, a quick pit stop: most modern data-intensive apps are built with a few trusty building blocks:

Databases: Your data's forever home.
Caches: The "are we there yet?" of system design—speeding up delivery by remembering answers.
Search Indexes: Like Google for your own app.
Stream Processing: Passing messages around asynchronously, so things don't get stuck waiting.
Batch Processing: When you need to crunch a mountain of data, preferably while you're sleeping.

Let's break down the big three:

1. Reliability: When "It Works on My Machine" Isn't Enough

Reliability means your system keeps working—even when the universe conspires against you. And trust me, it will.

The Usual Suspects

Hardware Faults: Hard drives die. Power goes out. Sometimes, the server room AC is set to sweat lodge mode. Modern systems assume hardware will fail and build in redundancy. Thank you, software engineers of the world!
Software Errors: Bugs, memory leaks, the infamous "works only on Tuesdays." Software can be sneaky—sometimes the bug only bites when you're on vacation.
Human Errors: Aka "I thought this was the staging database." Turns out, most outages are caused by us—humans. Guess we're not that reliable after all.

How Do We Fight Back?

Make it hard to mess up—sandbox environments, good tests, and big "Are you sure?" buttons help.
Recover quickly from mistakes.
Monitor everything. If a rocket needs telemetry to know what's going on after launch, your app probably needs it too.

The Human Side

Imagine a parent storing baby photos in your app. Now imagine those photos vanish forever. Yikes. Reliability isn't just a technical checkbox—it's about real people trusting you not to lose their memories. No pressure.

2. Scalability: Because "It Just Needs to Handle a Few Users" is a Lie

Every founder ever: "We'll just launch with a simple prototype." Six months later, you've got a viral TikTok and a server crying in the corner.

What Does "Scalable" Even Mean?

Saying "X is scalable" is about as useful as saying "X is delicious." It depends! As your data, traffic, and users grow, how does your system cope? What knobs can you turn when things get crazy?

Load Parameters (a.k.a. "How Much Stuff Are We Dealing With?")

Requests per second
Ratio of reads vs. writes
Number of active users
Cache hit rates
Or whatever metric keeps you up at night

The Twitter Example: To Fanout or Not to Fanout?

Approach 1: Read-time Fanout

Every time someone checks their timeline, grab all tweets from everyone they follow and merge them on the fly. (Spoiler: great for your first 200 users.)

SELECT tweets.*, users.* FROM tweets
JOIN users ON tweets.sender_id = users.id
JOIN follows ON follows.followee_id = users.id
WHERE follows.follower_id = current_user

Approach 2: Write-time Fanout

Every time someone tweets, stuff it into every follower's timeline cache. Now reading is cheap and fast—until Kim Kardashian logs in and breaks your database.

So Twitter…uses both. Most users get fast, precomputed timelines, but if you're super famous, your tweets get fetched and merged dynamically. Because, as always, "it depends."

Performance: It's Not Just About Averages

The book says to skip averages—focus on percentiles. Why? Because your angriest users are the ones stuck waiting at the 99.9th percentile.

X Percentile of a given request in this context means that there are X percentage of requests slower than the given.

Did you know Amazon found that a 100ms delay costs them 1% in sales? And a 1-second delay drops customer satisfaction by 16%? Now that's incentive to optimize.

Scaling Up vs. Scaling Out

Scaling Up: Bigger machines. (Vertical Scaling)
Scaling Out: More machines. (Horizontal Scaling)

Most real systems mix both.

And if you're looking for a "magic scaling sauce," sorry—every app is different. There's no secret recipe, just a lot of experience, trial, and error.

3. Maintainability: For the Future-You (and Your Team)

Let's be honest: most of the cost in software comes after you launch. Maintenance is where the real pain (and sometimes glory) is.

Three Principles to Live By

Operability:

Make it easy for ops teams to keep things running. Good ops can save bad software—but bad ops can sink even the best code.

Monitor everything.
Automate what you can.
Document everything.
Good defaults, but let experts override.

Simplicity:

Complexity is like glitter—you'll never get rid of it all, but you can try. Symptoms of "big ball of mud" syndrome: tangled dependencies, wild state space, special-case hacks, and naming that makes no sense.

Remove accidental complexity.
Use abstraction wisely.
Make it easy for new engineers to ramp up. (Don't make them solve a riddle to understand your code.)

Evolvability:

Change is the only constant. Your system should be able to adapt—new features, new requirements, new bosses with "just one more thing."

Keep things simple and well-abstracted.
Use practices like TDD and refactoring.
Remember, the next person who works on this code might be you…six months from now…at 3am.

Reflections (and a Pep Talk)

What struck me most about this chapter is how these three pillars—reliability, scalability, and maintainability—aren't just technical checkboxes. They're connected to the real world: to business outcomes, user happiness, and to our own sanity as engineers.

The Twitter example is more than a story; it's a peek into how real companies wrestle with trade-offs. And when Amazon says "milliseconds matter," you know the stakes are high.

System design isn't just about picking the fanciest tech. It's about making thoughtful trade-offs, learning from mistakes, and always, always thinking about the humans on the other side of the screen (and those who'll maintain your code later).

What's Next?

Next up: data models and query languages! (Spoiler: how you store and fetch data changes everything.) If you've ever wondered why NoSQL exists or whether SQL is secretly a wizard, you won't want to miss it.

What about you? Had any reliability horror stories? Ever scaled an app and watched it break gloriously? Or maybe you've inherited a "big ball of mud" codebase and lived to tell the tale? Drop your stories or questions in the comments—I'd love to hear them!

Buckle up—this journey's just getting started. 🚀

DEV Community: Saksham Malhotra

Go Beyond Basics: Closures, Interfaces, and Why Go Has No Inheritance

Closures

Stringer

No method overloading

Interface values are two-part boxes

Methods Can Belong to Any Named Type

Contract not Inheritance

Conclusion

Go Programming Language : Basics

Variables and Constants

Key points

Control Structures

Simple for loop

for loop used as a while loop

Infinite loop with break

if-else statement with inline initialization

switch statement

switch with time.Weekday()

Key Points

Data Structures: Arrays and Slices

Do slices in Go have different types of elements?

Arrays

Slices

Key Points

Data structures: Maps

Nil map

Creating and adding data to a map

Map literal

Access with existence check

Delete a key

Iterating over a map

Comparing maps

Key points

Functions

Basic Call

Multiple Return Values with Error Handling

Named return values

Variadic functions

Higher-order function

Key points

Closures and Pointers

Closures

Pointers

Structs and Custom Types

Custom type & method for it

Basic struct definition & Methods

Embedded struct

Creating a var of struct

Key Points

Example:

Interfaces

Define an interface

Independent types

Use of interfaces with types

Key points

Important points

Enums

Generics

Generic function with a type parameter

Using interface for constraints

Conclusion

"Designing Data-Intensive Applications": Chapter 2 - Graph like Data Models and Query Languages - Part III

Graph‑Like Data Models

But wait, what is a Graph? 🤔

Taking an example

Property Graph Model

Cypher Query Language

SQL with Recursive CTEs

Triple Stores & SPARQL

Semantic Web

Conclusion 🎯

Chapter 2: Designing Data-Intensive Applications - Data models - Part 2 : Query Languages

Declarative vs. Imperative Querying

What’s the Difference?

Why Declarative Wins

Declarative Queries on the Web

Why Declarative is Better

MapReduce Querying

Example Use Case

Simple `for` loop

`for` loop used as a `while` loop

Infinite loop with `break`

`if-else` statement with inline initialization

`switch` statement

`switch` with `time.Weekday()`