DEV Community: Saloni Agarwal

System Design: Building a Parking Lot System in Go

Saloni Agarwal — Sat, 09 Nov 2024 14:42:37 +0000

In this article, we’ll go through a low-level design (LLD) implementation of a parking lot system in Go. We'll explore different aspects of the system and see how each component interacts with the rest. This implementation focuses on clarity and real-world usefulness, so you can extend it easily if you want to add features like more vehicle types, multiple payment options, or spot reservations.

The system handles tasks like managing parking floors and spots, parking and unparking vehicles, and processing payments. We’ll also ensure it’s thread-safe for concurrent access, so if we need to expand it into a larger system, it won’t break down under pressure.

Core Components

Our design includes six main components:

Parking Lot - The main entry point managing floors and parking operations.
Parking Floor - Each floor contains multiple parking spots for different types of vehicles.
Parking Spot - Represents a parking spot that can hold a specific type of vehicle.
Parking Ticket - Tracks entry/exit times, parking charges, and the associated vehicle.
Payment System - Handles parking fee calculations and payment processing.
Vehicle Types - Supports different types of vehicles (cars, vans, trucks, and motorcycles). Each type has a different hourly charge.

Singleton Parking Lot

Our ParkingLot uses the Singleton pattern. This means there’s only one instance of the parking lot, which is created once and reused across the application. Here’s the code to get that working:

var (
    parkingLotInstance *ParkingLot
    once               sync.Once
)

type ParkingLot struct {
    Name   string
    floors []*ParkingFloor
}

func GetParkingLotInstance() *ParkingLot {
    once.Do(func() {
        parkingLotInstance = &ParkingLot{}
    })
    return parkingLotInstance
}

Using sync.Once, we ensure that only one instance is created, even when accessed by multiple goroutines.

Managing Floors in the Parking Lot

The parking lot has multiple floors, each with designated parking spots for different vehicle types (e.g., cars, vans, trucks, and motorcycles). To add a floor to the parking lot, we use the AddFloor method:

func (p *ParkingLot) AddFloor(floorID int) {
    p.floors = append(p.floors, NewParkingFloor(floorID))
}

Each floor is created using the NewParkingFloor function, which organizes spots by vehicle type.

Parking Spots

Each ParkingSpot is associated with a specific vehicle type (like a car or motorcycle). This allows the system to manage and restrict which vehicles can park in each spot. Here’s the ParkingSpot structure and the ParkVehicle method:

type ParkingSpot struct {
    SpotID         int
    VehicleType    vehicles.VehicleType
    CurrentVehicle *vehicles.VehicleInterface
    lock           sync.Mutex
}

func (p *ParkingSpot) ParkVehicle(vehicle vehicles.VehicleInterface) error {
    p.lock.Lock()
    defer p.lock.Unlock()

    if vehicle.GetVehicleType() != p.VehicleType {
        return fmt.Errorf("vehicle type mismatch: expected %s, got %s", p.VehicleType, vehicle.GetVehicleType())
    }
    if p.CurrentVehicle != nil {
        return fmt.Errorf("parking spot already occupied")
    }

    p.CurrentVehicle = &vehicle
    return nil
}

We use a Mutex lock to make sure only one vehicle can park in a spot at a time.

Parking Ticket

Every vehicle gets a ticket with the entry time, exit time, parking spot, and total charge. This ticket will be updated when the vehicle exits, and charges will be calculated based on the time spent parked.

type ParkingTicket struct {
    EntryTime   time.Time
    ExitTime    time.Time
    Vehicle     vehicles.VehicleInterface
    Spot        *ParkingSpot
    TotalCharge float64
}

func NewParkingTicket(vehicle vehicles.VehicleInterface, spot *ParkingSpot) *ParkingTicket {
    return &ParkingTicket{EntryTime: time.Now(), ExitTime: time.Time{}, Vehicle: vehicle, Spot: spot, TotalCharge: 0.00}
}

The CalculateTotalCharge method calculates parking fees based on the vehicle type and duration.

Payment System

The PaymentSystem class processes the payment, updating the payment status based on whether the required amount is paid:

type PaymentSystem struct {
    Status        Status
    Amount        float64
    ParkingTicket *ParkingTicket
}

func (p *PaymentSystem) ProcessPayment() error {
    if p.ParkingTicket == nil {
        return fmt.Errorf("payment failed: no parking ticket found")
    }
    if p.ParkingTicket.TotalCharge < p.Amount {
        p.Status = PaymentStatusFailed
        return fmt.Errorf("payment failed: insufficient funds")
    }

    p.Status = PaymentStatusCompleted
    return nil
}

The ProcessPayment function checks the amount and updates the payment status to Completed or Failed.

Adding Vehicle Types

Our system supports different types of vehicles (cars, vans, trucks, and motorcycles). Each type has a different hourly charge. This is achieved by setting up a VehicleType and VehicleInterface in a separate vehicles package:

package vehicles

type VehicleType string

const (
    CarType        VehicleType = "Car"
    VanType        VehicleType = "Van"
    TruckType      VehicleType = "Truck"
    MotorcycleType VehicleType = "Motorcycle"
)

type VehicleInterface interface {
    GetLicenceNumber() string
    GetVehicleType() VehicleType
    GetVehicleCost() float64
}

We can create new vehicles by calling NewCar, NewVan, NewTruck, etc., each of which implements VehicleInterface.

Bringing It All Together

Let’s see how the pieces fit together in a flow:

Create a Parking Lot: Call GetParkingLotInstance() and add floors with AddFloor.
Find Parking Spot and Park Vehicle: ParkVehicle method finds an available spot, validates it against the vehicle type, and generates a ticket.
Unpark Vehicle and Process Payment: UnparkVehicle generates the total charge, initiates the payment system, and completes the transaction.

This parking lot system is a simplified starting point for building more complex systems. We covered the basics of floor and spot management, vehicle parking and unparking, and a basic payment process.

For full code implementation, check the following repository:

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Welcome to the Low-Level System Design in Go repository! This repository contains various low-level system design problems and their solutions implemented in Go. The primary aim is to demonstrate the design and architecture of systems through practical examples.

Overview

Low-level system design involves understanding the core concepts of system architecture and designing scalable, maintainable, and efficient systems. This repository will try to cover solutions of various problems and scenarios using Go.

Parking Lot System

The first project in this repository is a Parking Lot System. This system simulates a parking lot where vehicles can be parked and unparked. It demonstrates:

Singleton design pattern for managing the parking lot instance.
Handling different types of vehicles (e.g., cars, trucks).
Parking space management across multiple…

View on GitHub

System Design: Building a Simple Social Media Platform in Go

Saloni Agarwal — Thu, 07 Nov 2024 11:07:43 +0000

In this article, we'll walkthrough the designing of a simplified social media platform using Go, focusing on low-level system design principles. Our platform includes core features like user registration, creating posts, handling likes and comments, and a notification system to keep users updated. This example illustrates how these features can be built into a system that’s modular, scalable, and efficient.

We'll use Go's concurrency capabilities and design patterns like the facade to create a streamlined and maintainable structure, allowing the platform to handle various user interactions seamlessly.

Key Components of Our Design

The social media platform we’re building focuses on these main features:

User Management: Registering and managing user profiles.
Post Creation and Interactions: Creating posts, liking, and commenting.
Notifications: Alerting users to relevant actions like likes and comments.
Concurrency: Efficiently handling simultaneous user actions.

Core Components of the System

Let’s break down the key components of our platform and see how each part integrates into the system.

User Management

The UserManager component is responsible for user registration and profile management. Each user has essential profile details like ID, name, and bio, and the manager ensures users can be added and retrieved efficiently. Some key functions are:

type User struct {
    type User struct {
    ID             int
    Name           string
    Email          string
    Password       string
    DisplayPicture *string
    Bio            *string
    friends        map[int]*User
    posts          []*Post
}

type UserManager struct {
    users map[int]*User
    mu    sync.RWMutex
}

func (um *UserManager) AddUser(user *User) {
    um.mu.Lock()
    defer um.mu.Unlock()
    um.users[user.ID] = user
    fmt.Printf("User added: %d\n", user.ID)
}

func (um *UserManager) GetUserByID(userID int) (*User, error) {
    um.mu.RLock()
    defer um.mu.RUnlock()
    user, ok := um.users[userID]
    if !ok {
        return nil, fmt.Errorf("user not found")
    }
    return user, nil
}

func (um *UserManager) AddFriend(requesterID, receiverID int) error {
    requester, err := um.GetUserByID(requesterID)
    if err != nil {
        return err
    }

    receiver, err := um.GetUserByID(receiverID)
    if err != nil {
        return err
    }

    requester.AddFriend(receiver)
    receiver.AddFriend(requester)
    fmt.Printf("Friendship added between users: %d and %d\n", requesterID, receiverID)
    return nil
}

In a real-world application, the UserManager would connect to a database, but here we use a map for simplicity.

Post Management

The PostManager handles user-generated content by managing posts, likes, and comments. This component allows users to create posts, like others’ posts, comment, and retrieve posts. Some key functions are:

type Post struct {
    ID              int
    UserID          int
    Content         string
    IsPublished     bool
    URLs            []*string
    Likes           int
    Comments        []*Comment
    PublishedAt     time.Time
    CommentsEnabled bool
    HiddenFromUsers map[int]bool
}

type PostManager struct {
    posts map[int]*Post
    mu    sync.RWMutex
}

func (pm *PostManager) GetPost(postID int) (*Post, error) {
    pm.mu.RLock()
    defer pm.mu.RUnlock()

    post, exists := pm.posts[postID]
    if !exists {
        return nil, fmt.Errorf("post not found")
    }
    return post, nil
}

func (pm *PostManager) AddPost(post *Post, user *User) {
    pm.mu.Lock()
    defer pm.mu.Unlock()
    pm.posts[post.ID] = post

    user.AddPost(post)
}

func (pm *PostManager) LikePost(postID int) (*Post, error) {
    pm.mu.Lock()
    post := pm.posts[postID]
    pm.mu.Unlock()

    if post == nil {
        return nil, fmt.Errorf("post not found")
    }

    pm.mu.Lock()
    defer pm.mu.Unlock()

    post.Like()
    return post, nil
}

The PostManager could interact with a database to store and retrieve posts, allowing for filtering by various criteria.

Notification Management

The NotificationManager is responsible for keeping users updated on platform activities, such as receiving a like or comment on their posts. Each notification type (like, comment, friend request) is sent through this manager, ensuring users are informed in real-time. Some key functions are:

type Notification struct {
    ID      string
    Type    NotificationType
    Content string
    UserID  int
}

type NotificationManager struct {
    notifications map[int][]*Notification
    mu            sync.RWMutex
}

func (nm *NotificationManager) AddNotification(userID int, notificationType NotificationType, message string) {
    nm.mu.Lock()
    defer nm.mu.Unlock()

    notification := NewNotification(fmt.Sprintf("notification-%d", time.Now().UnixMicro()), notificationType, message, userID)
    nm.notifications[userID] = append(nm.notifications[userID], notification)
}

func (nm *NotificationManager) GetNotificationsForUser(userID int) ([]*Notification, error) {
    nm.mu.RLock()
    defer nm.mu.RUnlock()

    notifications, ok := nm.notifications[userID]
    if !ok {
        return nil, fmt.Errorf("user not found")
    }
    return notifications, nil
}

With NotificationManager, we can notify users of interactions related to their posts, allowing for a more engaging experience. In a production system, notifications could be sent via channels or push notifications.

Using the Facade Pattern with ActivityFacade

To simplify interactions between different components, we use the Facade pattern. ActivityFacade combines the functionalities of UserManager, PostManager, and NotificationManager, providing a unified interface for our social media app.

type ActivityFacade struct {
    userManager       *UserManager
    postManager       *PostManager
    notificationManager *NotificationManager
}

func (af *ActivityFacade) SendFriendRequest(requesterID, receiverID int) error {
    _, err := af.UserManager.GetUserByID(receiverID)
    if err != nil {
        return err
    }

    af.NotificationManager.AddNotification(receiverID, FriendRequestNotificationType, fmt.Sprintf("%d has sent you a friend request", requesterID))

    fmt.Printf("Friend request sent to user %d\n", receiverID)
    return nil
}

func (af *ActivityFacade) CommentPost(userID, postID int, content string) error {
    user, err := af.UserManager.GetUserByID(userID)
    if err != nil {
        return err
    }

    post, err := af.PostManager.CommentPost(user, postID, content)

    af.NotificationManager.AddNotification(post.UserID, CommentNotificationType, fmt.Sprintf("%d has commented on your post: %d", userID, post.ID))

    fmt.Printf("Comment added to post: %d\n", post.ID)
    return nil
}

func (af *ActivityFacade) HidePostFromUser(postID int, userID int) error {
    _, err := af.UserManager.GetUserByID(userID)
    if err != nil {
        return err
    }

    return af.PostManager.HidePostFromUser(postID, userID)
}

With ActivityFacade, we can streamline user interactions with the platform, reducing the complexity of directly managing each subsystem. This approach makes the code more modular, maintainable, and easier to expand.

Handling Concurrency

In any social media platform, multiple users perform actions simultaneously. Go’s concurrency tools, particularly sync’s RWMutex, are ideal for handling concurrent reads and writes in a safe way.

Using RWMutex, we ensure that multiple users can read posts concurrently, but only one can like or comment at a time, preventing race conditions and data corruption.

Conclusion and next steps

Our low-level system design for a social media platform in Go provides a strong foundation for expanding features making it scalable and easy to maintain.

Potential areas for future enhancement include:

Real-time Notifications using WebSockets or push notifications.
Advanced Privacy Controls for friend requests and posts.
Persistent Data Storage with a database to replace the in-memory maps.

For full code implementation, please check the following repository:

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Overview

Parking Lot System

The first project in this repository is a Parking Lot System. This system simulates a parking lot where vehicles can be parked and unparked. It demonstrates:

Singleton design pattern for managing the parking lot instance.
Handling different types of vehicles (e.g., cars, trucks).
Parking space management across multiple…

View on GitHub

System design: Building a Vending Machine in Go

Saloni Agarwal — Mon, 04 Nov 2024 11:10:31 +0000

Living in Tokyo, Japan, I’m surrounded by vending machines offering everything from hot coffee to cold drinks and snacks.Inspired by these iconic machines, I trued to build a vending machine system design in Go. It's a cool example of using the State pattern, and I'll break down why it's super useful for this kind of project.

Why a Vending Machine?

Think about a real vending machine - it's actually pretty complex! It needs to:

Keep track of products and their quantities
Handle money
Make sure you've put in enough cash
Give you your snack
Return your change

Plus, it needs to do all this without getting confused about what state it's in.

The Basic Building Blocks

First up, I needed some basic structures to work with:

Products and Inventory
Each product has an ID, name, price, and quantity. Pretty straightforward stuff:

type Product struct {
    ID       int
    Name     string
    Price    float64
    Quantity int
}

The inventory keeps track of all products using a map. It can:

Add new products
Remove products
Handle transactions (like when someone buys something)
Check if products are available

The State Pattern: Why It's Awesome Here

Here's where it gets interesting. A vending machine can be in different states:

Waiting for money
Money inserted
Product selected
Dispensing product

Each state needs to handle user actions differently. Like, you can't select a product before putting in money, right?
I used three main states:

MoneyInsertedState
ProductSelectedState
ProductDispensedState

Each state implements this interface:

type State interface {
    InsertMoney(amount float64)
    SelectProduct(product *Product)
    ReturnChange()
    DispenseProduct()
}

How It All Works Together

Let's say you want to buy a Coke:

First, you insert $2.00

The machine is in MoneyInsertedState
It records your money
Switches to ProductSelectedState

You select Coke ($1.50)

Machine checks if it has Coke in stock
Verifies you put in enough money
Moves to ProductDispensedState

Machine dispenses your Coke

Updates inventory
Returns your $0.50 change
Goes back to MoneyInsertedState

Cool Features I Added

Stock Management: Each product starts with 3 units. When something's sold out, it's automatically removed from available options.
Smart Change Handling: The machine always calculates and returns the correct change after a purchase.
Error Prevention: The state pattern helps prevent weird situations like, trying to buy stuff without enough money, selecting products that are out of stock, inserting money while something's being dispensed.

What I Learned

Building this taught me a few things:

The State pattern is perfect for machines with clear, distinct states
Go's interfaces make implementing state patterns really clean
Proper error handling is super important for real-world applications

What's Next?

There's always room for improvement! Some ideas:

Add support for card payments
Implement a display system
Add temperature monitoring for drinks
Create an admin interface for restocking

The full code is more detailed than what I showed here, but these are the main pieces that make it work. Feel free to check the full implementation in the following repo:

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Overview

Parking Lot System

The first project in this repository is a Parking Lot System. This system simulates a parking lot where vehicles can be parked and unparked. It demonstrates:

Singleton design pattern for managing the parking lot instance.
Handling different types of vehicles (e.g., cars, trucks).
Parking space management across multiple…

View on GitHub

Building a Simple Blockchain in Golang

Saloni Agarwal — Sun, 03 Nov 2024 05:25:58 +0000

In this article, we’ll try to walk through building a basic blockchain using Go. We’ll cover the essentials of block structure, hashing, and transaction validation using SHA-256, which is more secure than MD5.

Why Go for Blockchain?

Go is an efficient and easy-to-learn language that’s great for projects involving concurrency and speed—both crucial for blockchain implementations.

Blockchain Basics

A blockchain is a series of blocks linked by cryptographic hashes. Each block contains:

Data: Information stored in the block, like transaction details.
Hash: A SHA-256 hash of the block’s content.
Previous Hash: The hash of the previous block, linking blocks together.
Nonce: A value used in mining to adjust the hash.

With this setup, we ensure each block in the chain is uniquely identifiable and tamper-resistant.

Defining the Block Structure

In Go, we define each block with fields for Data, Hash, PrevHash, Nonce, and Transactions.

type Block struct {
    Hash         string
    Data         string
    PrevHash     string
    Nonce        int
    Transactions []*Transaction
}

Computing SHA-256 Hashes

To secure each block, we use SHA-256 to compute the hash based on the block’s data and previous hash.

func (b *Block) ComputeHash() {
    data := b.Data + b.PrevHash
    hash := sha256.Sum256([]byte(data))
    b.Hash = hex.EncodeToString(hash[:])
}

Creating the Genesis Block

The genesis block is the first block in our blockchain, initialized with a unique “coinbase” transaction to establish a starting point.

func Genesis() *Block {
    coinbaseTx := &Transaction{Sender: "Coinbase", Receiver: "Genesis", Amount: 0.0}
    return CreateBlock("Genesis Block", "", []*Transaction{coinbaseTx})
}

Structuring the Blockchain

Our blockchain consists of an array of blocks. We initialize it with the genesis block.

type Blockchain struct {
    Blocks []*Block
}

func InitBlockChain() *Blockchain {
    return &Blockchain{[]*Block{Genesis()}}
}

Proof-of-Work and Mining

To add blocks, we need a Proof-of-Work algorithm that finds a hash satisfying a target condition. This process involves incrementing the Nonce until the hash meets the target difficulty, ensuring blocks are not trivially added.

Wallets and Transactions

To simulate wallet functionality, we generate RSA keys to sign and verify transactions.

Creating Wallets: Each wallet has a public and private key.
Signing Transactions: Transactions are signed by the sender’s private key for validation.
Verifying Transactions: Recipients can verify transactions using the sender’s public key, ensuring authenticity.

Example: Using the Blockchain

Here’s how we’d use the blockchain:

Initialize the blockchain.
Create wallets for participants (e.g., Alice and Bob).
Add transactions, sign them with Alice’s private key, and add them to a new block.
Display the blockchain’s content for verification.

func main() {
    chain := InitBlockChain()
    // Sample wallets and transaction setup
    // Display chain information
    for _, block := range chain.Blocks {
        fmt.Printf("PrevHash: %s\nData: %s\nHash: %s\n", block.PrevHash, block.Data, block.Hash)
    }
}

This project covers the core components of blockchain—structuring, hashing, proof-of-work mining, and transaction validation with digital signatures. Our SHA-256 hashing ensures secure and unique identifiers for each block, while RSA-based wallets add basic transaction validation.

This blockchain implementation is a simplified model. To further develop it, you could:

Add persistent storage for blocks.
Implement peer-to-peer networking.
Add more sophisticated validation for transactions.

To see the full implementation from scratch, please refer to the following repo:

thesaltree / blockchain-golang

Blockchain implementation in Golang

Blockchain Implementation in Golang

A blockchain implementation in Go, demonstrating essential concepts of blockchain technology. This project includes basic block structures, proof-of-work consensus, cryptographic transaction signing, and block verification.

Features

Block Structure: Each block holds data, a hash, a previous hash link, a nonce, and transactions.
Proof of Work (PoW): Implements a proof-of-work system using md5 hashing to maintain blockchain integrity.
Wallets and Transactions: Supports RSA key pairs for wallets, transaction creation, signing, and verification.
Genesis Block: Automatically creates the genesis (first) block with a Coinbase transaction.
CLI Demo: Demonstrates the creation of blocks, transactions, and verification on the blockchain.

Installation

Prerequisites

Go version 1.16 or higher.

Setup

Clone the repository:

git clone https://github.com/thesaltree/blockchain-golang.git
cd blockchain-golang
go mod tidy

Run the project:

go run main.go

View on GitHub

System Design: Library Management System

Saloni Agarwal — Thu, 31 Oct 2024 13:43:21 +0000

Building a Library Management System in Go

In this article, let's explore a Library Management System (LMS) implemented in Go, highlighting its core features, design decisions, and key code snippets.

Core Features of the Library Management System

Book Management

The system supports multiple copies of each book, allowing for efficient tracking and management of inventory. Each book has properties such as ID, title, author, publication year, and a slice of BookItem, which represents the individual copies.

type Book struct {
    ID            int
    BookItem      []BookItem
    Title         string
    Author        string
    PublishedYear string
    mu            sync.RWMutex
}

Member Management

Members can borrow books, and the system tracks their borrowing history. Each member has a borrowing quota, ensuring they can borrow a limited number of books at any given time.

type Member struct {
    ID              int
    Name            string
    ContactInfo     string
    CurrentBorrowed []*BookItem
    BorrowHistory   []*BookItem
}

Borrowing and Returning Books

The borrowing mechanism checks for available copies and updates their status accordingly. The system allows members to return books, updating the book's status and tracking the transaction in the member's borrowing history.

func (m *Member) AddBorrowedBook(bookItem *BookItem) {
    m.CurrentBorrowed = append(m.CurrentBorrowed, bookItem)
}

func (l *Library) BorrowBookByMember(memberID int, bookID int) *BookItem {
    // Logic to borrow a book
}

Concurrency Control

Utilizing Go's concurrency features, the system handles multiple borrowing and returning requests simultaneously. The use of sync.RWMutex ensures that book availability checks and updates are thread-safe, preventing race conditions.

func (b *Book) IsBookAvailable() bool {
    b.mu.RLock()
    defer b.mu.RUnlock()
    for _, bookCopy := range b.BookItem {
        if bookCopy.Status == Available {
            return true
        }
    }
    return false
}

Overdue Book Management

The system checks if borrowed books are overdue, implementing business rules to notify members and possibly charge fines.

func (bi *BookItem) IsOverdue() bool {
    if bi.Status != Borrowed {
        return false
    }
    return time.Since(bi.LastBorrowed) > time.Hour*24*7
}

Design Decisions

Why Go?
Go was chosen for its simplicity, efficiency, and built-in support for concurrency, which is crucial for handling multiple requests in a library setting. Its strong typing and compile-time checks help reduce bugs and improve code maintainability.

Singleton Pattern for Library Instance
The system uses a singleton pattern to manage a single instance of the library. This design ensures that all operations (adding books, managing members) are centralized, simplifying resource management.

var (
   libraryInstance *Library
   once            sync.Once
)

func GetLibraryInstance() *Library {
   once.Do(func() {
       libraryInstance = &Library{books: make(map[int]*Book), members: make(map[int]*Member)}
   })
   return libraryInstance
}

Encapsulation and Data Protection
The use of mutexes (sync.RWMutex) protects shared resources and ensures that concurrent access does not lead to inconsistent states. This encapsulation is crucial in a multi-user environment where multiple members may be interacting with the system simultaneously.

Please explore the complete code and contribute to further enhancements in the following repository:

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Overview

Parking Lot System

The first project in this repository is a Parking Lot System. This system simulates a parking lot where vehicles can be parked and unparked. It demonstrates:

Singleton design pattern for managing the parking lot instance.
Handling different types of vehicles (e.g., cars, trucks).
Parking space management across multiple…

View on GitHub

Why Golang’s Concurrency conquers over PHP

Saloni Agarwal — Mon, 28 Oct 2024 11:21:32 +0000

If you’re building apps that need to handle a bunch of stuff at once, like real-time data processing or tons of simultaneous requests, PHP and Go don’t even compare. Go just gets concurrency, while PHP feels like it’s struggling to keep up. Let’s dig into why Go’s concurrency model is a game-changer.

PHP’s Concurrency issues

PHP was never really built for handling multiple tasks at once. Each request is handled in a single process, one task at a time. This works fine for typical web apps (like CMS or e-commerce platforms), but if you try doing real-time data or concurrent processing, PHP hits a wall fast. You can use tools like ReactPHP or PHP threading extensions to force some level of concurrency, but it’s clunky. These workarounds add a layer of complexity and don’t play nicely with PHP’s ecosystem, which just ends up creating a mess.

From my experience, handling concurrency in PHP feels like patching a leaky boat—there’s always something else that needs fixing, and scaling becomes a nightmare.

Go’s Concurrency solutions

Go’s concurrency model, though, is next level. Go has this thing called goroutines, which are like super-lightweight threads. You can run thousands of these without draining your system’s resources. Want to run multiple API requests at once? Just spin up a goroutine for each one, and they all handle their work side-by-side. Then, channels let you pass data between these goroutines, keeping everything in sync.

The first time I used Go for a project that needed real-time data processing, I was honestly shocked at how smooth it was. No extra libraries, no weird setups—just fast, efficient concurrency right out of the box.

My take

For a basic website, PHP is fine, but if your project involves heavy-duty, parallel tasks, Go’s a total game-changer. It’s not just faster—it changes how you think about building and scaling your app. If you need real concurrency, Go’s the clear winner.

Composition Over Inheritance in Golang

Saloni Agarwal — Sun, 27 Oct 2024 06:05:18 +0000

When designing software, the "composition over inheritance" principle often leads to more flexible, maintainable code. Go, with its unique approach to object-oriented design, leans heavily into composition rather than inheritance. Let's see why.

Why Go Prefers Composition

In traditional OOP languages, inheritance lets one class inherit behaviors and properties from another, but this can lead to rigid, hard-to-change hierarchies. Go avoids inheritance altogether and instead encourages composition—where types are built by combining smaller, focused components.

Composition in Action

Imagine we’re modeling a company with different types of workers: some are engineers, some are managers, and some are interns. Instead of creating a complex class hierarchy, we’ll define specific behaviors as independent types and then compose them.

Example: Worker Behaviors in Go

package main

import "fmt"

type Worker interface {
    Work()
}

type Payable struct {
    Salary int
}

func (p Payable) GetSalary() int {
    return p.Salary
}

type Manageable struct{}

func (m Manageable) Manage() {
    fmt.Println("Managing team")
}

type Engineer struct {
    Payable
}

func (e Engineer) Work() {
    fmt.Println("Engineering work being done")
}

type Manager struct {
    Payable
    Manageable
}

func (m Manager) Work() {
    fmt.Println("Managerial work being done")
}

Here:

Engineer and Manager embed Payable, giving them a Salary.
Manager also embeds Manageable, giving them team management abilities.
Each type implements Work() individually, satisfying the Worker interface.

Benefits of Composition

Simplicity: Each behavior is encapsulated in its struct, making it easy to extend.
Flexibility: New types or behaviors can be added without breaking existing code.
Reusability: Behaviors are modular, so we can easily combine them in different ways.

Using Interfaces with Composition

In Go, interfaces and composition work together to allow polymorphism without inheritance. Here’s how we can handle multiple worker types with a single function:

func DescribeWorker(w Worker) {
    w.Work()
}

func main() {
    engineer := Engineer{Payable{Salary: 80000}}
    manager := Manager{Payable{Salary: 100000}, Manageable{}}
    DescribeWorker(engineer)
    DescribeWorker(manager)
}

Go’s preference for composition over inheritance isn’t just a language quirk—it encourages cleaner, more modular code that’s adaptable to change. Instead of rigid hierarchies, you get flexible, reusable components that keep your codebase nimble and easy to maintain.

Elevator Scheduling Algorithms: FCFS, SSTF, SCAN, and LOOK

Saloni Agarwal — Sun, 27 Oct 2024 05:18:26 +0000

Since I’ve been working with Go for quite some time, I thought it would be a fun challenge to implement a few classic low-level design solutions in it.

When designing an elevator system, one crucial aspect is how to decide which floor to service next, especially when the elevator has multiple requests. Go’s straightforward syntax and performance make it ideal for modeling such systems, so I set out to create basic implementations of FCFS (First Come First Serve), SSTF (Shortest Seek Time First), SCAN, and LOOK algorithms.

1. First Come First Serve (FCFS)

I started with the simplest approach: service requests in the order they’re received. It’s easy to implement but can be inefficient if the requests are spread out across floors, leading to more travel time.

func FCFS(currentFloor int, requests []int) []int {
    path := []int{}
    for _, floor := range requests {
        path = append(path, floor)
    }
    return path
}

In FCFS, the elevator simply moves to each requested floor in the given order.

2. Shortest Seek Time First (SSTF)

SSTF tries to minimize travel by choosing the closest requested floor next. This reduces travel time but can lead to "starvation" for far-off requests if new closer requests keep coming.

func SSTF(currentFloor int, requests []int) []int {
    path := []int{}
    remaining := append([]int{}, requests...)

    for len(remaining) > 0 {
        closestIdx := 0
        minDistance := abs(currentFloor - remaining[0])

        for i, floor := range remaining {
            distance := abs(currentFloor - floor)
            if distance < minDistance {
                closestIdx = i
                minDistance = distance
            }
        }

        currentFloor = remaining[closestIdx]
        path = append(path, currentFloor)
        remaining = append(remaining[:closestIdx], remaining[closestIdx+1:]...)
    }
    return path
}

func abs(x int) int {
    if x < 0 {
        return -x
    }
    return x
}

This function finds the closest floor to the current floor each time, updating the elevator’s position after each move.

3. SCAN (Elevator Algorithm)

In SCAN, the elevator moves in one direction, servicing all requests in that direction until it reaches the end, then reverses. This approach is more fair than SSTF because it reduces starvation.

func SCAN(currentFloor, maxFloor int, requests []int) []int {
    path := []int{}
    up := []int{}
    down := []int{}

    for _, floor := range requests {
        if floor >= currentFloor {
            up = append(up, floor)
        } else {
            down = append(down, floor)
        }
    }

    sort.Ints(up)
    sort.Sort(sort.Reverse(sort.IntSlice(down)))

    path = append(path, up...)
    path = append(path, down...)
    return path
}

This function splits requests into floors above and below the current position. It serves all floors upwards, then downwards.

4. LOOK

LOOK is a slight variation of SCAN. Instead of going all the way to the end, the elevator reverses direction at the last request in each direction. It saves time by stopping where the requests end, not at the physical limits.

func LOOK(currentFloor int, requests []int) []int {
    path := []int{}
    up := []int{}
    down := []int{}

    for _, floor := range requests {
        if floor >= currentFloor {
            up = append(up, floor)
        } else {
            down = append(down, floor)
        }
    }

    sort.Ints(up)
    sort.Sort(sort.Reverse(sort.IntSlice(down)))

    path = append(path, up...)
    path = append(path, down...)
    return path
}

Similar to SCAN, this approach only moves as far as the last request in each direction.

Each algorithm has its trade-offs:

FCFS: Simple but can be inefficient.
SSTF: Optimizes for closest floors but can starve far-off requests.
SCAN: Fairer and efficient, minimizing direction changes.
LOOK: Saves additional time by stopping at the last request.

The right choice depends on the specific requirements for efficiency, fairness, and response time in the system.

For full implementation using LOOK algorithm, refer to my github repo:

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Overview

Parking Lot System

The first project in this repository is a Parking Lot System. This system simulates a parking lot where vehicles can be parked and unparked. It demonstrates:

Singleton design pattern for managing the parking lot instance.
Handling different types of vehicles (e.g., cars, trucks).
Parking space management across multiple…

View on GitHub

DEV Community: Saloni Agarwal

System Design: Building a Parking Lot System in Go

Core Components

Singleton Parking Lot

Managing Floors in the Parking Lot

Parking Spots

Parking Ticket

Payment System

Adding Vehicle Types

Bringing It All Together

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Table of Contents

Overview

Parking Lot System

System Design: Building a Simple Social Media Platform in Go

Key Components of Our Design

Core Components of the System

Using the Facade Pattern with ActivityFacade

Handling Concurrency

Conclusion and next steps

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Table of Contents

Overview

Parking Lot System

System design: Building a Vending Machine in Go

Why a Vending Machine?

The Basic Building Blocks

Cool Features I Added

What I Learned

What's Next?

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Table of Contents

Overview

Parking Lot System

Building a Simple Blockchain in Golang

Why Go for Blockchain?

Blockchain Basics

Defining the Block Structure

Proof-of-Work and Mining

Wallets and Transactions

Example: Using the Blockchain

thesaltree / blockchain-golang

Blockchain implementation in Golang

Blockchain Implementation in Golang

Features

Installation

Prerequisites

Setup

System Design: Library Management System

Building a Library Management System in Go

Core Features of the Library Management System

Design Decisions

thesaltree / low-level-design-golang

Low level system design solutions in Golang

Low-Level System Design in Go

Table of Contents

Overview

Parking Lot System

Why Golang’s Concurrency conquers over PHP

PHP’s Concurrency issues

Go’s Concurrency solutions

My take

Composition Over Inheritance in Golang

Why Go Prefers Composition

Composition in Action

Example: Worker Behaviors in Go

Benefits of Composition

Using Interfaces with Composition

Elevator Scheduling Algorithms: FCFS, SSTF, SCAN, and LOOK

1. First Come First Serve (FCFS)

2. Shortest Seek Time First (SSTF)

3. SCAN (Elevator Algorithm)

4. LOOK

thesaltree / low-level-design-golang