ngosangns Knowledge Base

Technical Solutions

#technology#system-design#case-study

Updated: 2026-09-24

Source

A catalog of write-ups on specific backend problems, grouped by area: authentication and authorization, caching, background jobs, IDs, rate limiting, migrations, and traffic spikes. Each entry links to the original article and states the problem it solves, so the page works as an index before it works as a reference. Treat it as a reading queue, and open the source when you need the full argument.

Authentication and Authorization

JWT (JSON Web Tokens)

Optimization

Memory Optimization

Performance Optimization

Caching

Data and Task Processing

Background Jobs / Queues

Logging

Data Compression (zip, gzip)

How Discord Cut Websocket Traffic by 40%

Discord reduced websocket traffic by 40% by:

  • Switching from zlib to the zstandard streaming compression algorithm. Streaming zstandard is superior in speed, memory usage, and compression ratio.
  • Changing the logic for updating data from server to client (passive sessions) to minimize redundant data.

Large File Upload

Data Syncing

Metadata

Data Backup

Communication and Notification

OTP (One-Time Password)

Notifications

Chat / Real-time Communication

Email

Specific Systems

E-commerce

Social Networks

Video Streaming (HLS)

  • HLS (HTTP Live Streaming): a live video streaming protocol based on HTTP, developed by Apple. HLS splits video into small segments, letting clients request these segments over HTTP and adapt to varying network conditions by switching between streams of different quality.

Recommendation Systems / Suggestion Algorithms

  • Collaborative-Filtering: a GitHub repository providing guidance and sample code for the Collaborative Filtering algorithm, a popular technique in recommendation systems based on the behavior of similar users or similar items.

Geography-based Solutions

  • The problem of batching orders to optimize delivery time: a discussion in the J2Team Community Facebook group about optimizing how orders are grouped to minimize delivery time, a real-world logistics problem that may involve route optimization algorithms (e.g. the Traveling Salesman Problem).

URL Shortening (TinyURL)

Design a URL shortening system like TinyURL.

  • Requirements:
    • Take a long URL and return a short URL.
    • When the short URL is visited, redirect to the original long URL.
    • The short URL must be unique.
    • Ability to customize the short URL (optional).
    • Click analytics (optional).
  • Main components:
    • Application Service: handles logic, creating the short code, and storage.
    • Database: stores the mapping between short URLs and long URLs.
      • NoSQL (e.g. Cassandra, DynamoDB) can be used for fast reads and writes and high scalability.
      • Key: short code, Value: long URL.
    • ID Generator: creates a unique short code.
      • Approach 1: Base62 encoding of an incrementing integer (needs a synchronization mechanism to avoid duplicates in a distributed system, e.g. using Zookeeper, or a dedicated ID-generating service).
      • Approach 2: generate a UUID, then hash it and take a portion.
      • Approach 3: pre-generate a large number of IDs and store them in the DB.
    • Load Balancer: distributes load across the application services.
    • Caching: cache frequently accessed short URLs to reduce DB load.
  • Flow:
    • Creating a short URL: user submits long URL -> Load Balancer -> Application Service -> ID Generator creates a short code -> Application Service saves (short code, long URL) to the DB -> returns the short URL to the user.
    • Redirecting: user visits the short URL -> Load Balancer -> Application Service -> looks up the corresponding long URL in the Cache, falling back to the DB if absent -> returns an HTTP 301/302 redirect to the long URL.
  • Considerations:
    • Scalability: shard the DB by short code, stateless application services.
    • Availability: DB replication, multiple application service instances.
    • Latency: caching, choosing a suitable DB.
  • Source: https://www.threads.net/@viettranx89/post/C_ZdnH-B9DI
  • Protip from the source: approach the problem as an MVP first, solve the core design, and only then expand. Clarify the constraints on actors (locks, race conditions, chosen protocol) before thinking about scalability.

Distributed Counter

For use cases like counting views, likes, and votes, there are several approaches (an integer counter in an RDBMS, a message queue, INCR in Redis, HyperLogLog). When high scalability is required and strong consistency is not (eventual consistency with low latency is acceptable), you can use a Conflict-free Replicated Data Type (CRDT).

Search & Autocomplete

Practice from Twitter

A blog post from Twitter (X) Engineering about the efforts and solutions used to ensure the stability and scalability of their search system.

Discussion of Autocomplete Solutions

  • Some ideas:
    • Use Spark Graph, HDFS, and Cloud Hadoop to implement a Trie.
    • Shard the data: each cluster stores some prefixes, with a proxy for routing. The challenge is splitting so requests are evenly distributed.
    • Sync data to a shared DWH, and use Spark/Hadoop to query + caching.
    • Use Elasticsearch (GitHub uses it too).
  • Discussion source: https://www.facebook.com/groups/sydexa/permalink/1775084429648431/

Prefixy - A Prefix Search Service for Autocomplete

Prefixy is a scalable prefix search service designed to power autocomplete features.

Other Libraries

ID Generation

  • Building GHTK's ID generation system - 100 million IDs / second: a video from Giao Hàng Tiết Kiệm (GHTK) about how they built an ID generation system capable of producing 100 million IDs per second. Key factors include uniqueness, ordering (optional), scalability, and high performance. - Source: https://www.youtube.com/watch?v=bSyFHY3a3_s

Operations and Monitoring

System Monitoring

Rate Limiting

Benchmarking

Tools for measuring system performance and load.

Technologies and Platforms

Serverless

Message Brokers (Kafka, RabbitMQ)

Message queue systems used for asynchronous communication between services.

  • Zero Disk Architectures - stateless broker: a stateless broker architecture that uses external storage (e.g. S3) to hold state, making the broker easy to scale and recover.
    • WarpStream
    • AutoMQ

Distributed Computing

  • Hadoop: an open-source framework for processing and storing large datasets in a distributed fashion.

Distributed Data Join & Mapping

  • Hasura: provides an instant GraphQL API over new or existing data sources, making it easy to combine data from multiple sources.
  • Krakend: a high-performance API Gateway with middleware for transforming, aggregating, and filtering data from multiple microservices.

AI / Machine Learning

  • SaaS AI models: Replicate is a platform for running AI/Machine Learning models in the cloud without managing infrastructure. It provides an API to easily integrate AI models into applications.
  • Practice building LLM + RAG on AWS: a post in the AWS Study Group FCJ Facebook group sharing hands-on experience building a large language model (LLM) with Retrieval Augmented Generation (RAG) on the AWS platform.

System Migration and Modernization

A Tale of Incremental Modernisation

A large customer in the UK and Ireland running a legacy system on a Mainframe faced difficulties with cost, speed of change, and staffing. The Thoughtworks team was asked to replace it and migrate the system to the Cloud.

Database Migration

Versioning

  • How to name versions: an article from ByteByteGo explaining what the numbers in software version naming mean, usually following Semantic Versioning (Major.Minor.Patch).

Web Crawling

  • Puppeteer: a Node.js library providing a high-level API to control Chrome/Chromium via the DevTools Protocol. Commonly used for crawling, scraping, and UI test automation.

Text & Editor

Scaling for Traffic Spikes

See also: Overview · Fundamentals · Retry And Circuit Breaker