--- title: "45/60 Days System Design Questions!" url: https://daily.dev/posts/45-60-days-system-design-questions--rtkojksa7 source_url: https://daily.dev/posts/45-60-days-system-design-questions--rtkojksa7 type: freeform source: "Joud Awad" author: "Joud Awad" published: 2026-06-20T16:26:52.503Z updated: 2026-06-20T16:27:36.122Z reading_time: 1 upvotes: 77 comments: 16 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 45/60 Days System Design Questions! **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 1 min read · 77 upvotes · 16 comments ## Summary A system design challenge presents a real-world search performance problem: a SaaS platform with 100M documents where PostgreSQL full-text search has degraded to p95=4.2s, with a target of sub-200ms at p99. Four options are presented — migrating to Elasticsearch, adding GIN indexes on tsvector columns, caching top queries in Redis, or switching to Typesense/Meilisearch — with the claim that three address something real but only one solves the actual problem. Readers are invited to pick an answer before a full breakdown is shared in comments. ## Content Your search box returns results in 80ms. Then you add 50M more documents. Now it's 4 seconds. Your DBA says "add an index." Your search engineer says "that's not how this works." They're both right — about different things. Here's the setup: Platform: SaaS product, 100M documents Search fields: title, description, tags, partial phrases Current stack: PostgreSQL full-text search Current perf: p95 = 4.2s Target: sub-200ms at p99 Product is escalating. What do you do? A) Migrate to Elasticsearch — inverted index, purpose-built for full-text, sub-100ms at scale. B) Add GIN indexes on your PostgreSQL tsvector columns — no new infra, meaningful performance gain. C) Cache the top 1,000 most common queries in Redis — free win for the majority of traffic. D) Move to Typesense or Meilisearch — simpler ops than Elasticsearch, built for search. Three of these solve something real. Only one solves the problem you actually have. Pick one — A, B, C, or D — and tell me why. I'll drop the full breakdown in the comments (including why two "almost right" answers get you partway there and then hit a wall). Drop your answer 👇 #30DaysOfSystemDesign #SystemDesign #Database #BackendEngineering ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 16 upvotes > **Why A wins (Elasticsearch):** > > Elasticsearch is built on an inverted index. When you index a document, Elasticsearch tokenizes the text and writes posting lists: "database" → [doc_1, doc_5, doc_23...], "index" → [doc_2, doc_5, doc_18...]. A query for "database index" does a fast posting-list intersection — not a table scan. > > > At 100M documents, that intersection still runs in milliseconds because posting lists are stored in delta-compressed sorted form, Lucene segments are immutable (no row locking, no MVCC overhead), horizontal sharding is native (queries fan out in parallel), and BM25... **@joudawad** · 9 upvotes > **Why B is the trap answer (GIN indexes on PostgreSQL):** > > GIN indexes on tsvector are genuinely good. For 1M–5M documents, this is the right call — no new infra, no ops burden, real improvement. > > > At 100M documents, you hit three walls: index size balloons (GIN is large — easily 40–80GB), PostgreSQL full-text has no native horizontal read scaling, and BM25 relevance scoring is bolted on, not native. You get from 4.2s down to maybe 500ms. You need 200ms. Close, but the wrong tool at this scale. > > > GIN is what you reach for before you need a dedicated search engine, not instead of one. **@joudawad** · 8 upvotes > **Why D is tempting but limited (Typesense / Meilisearch):** > > Typesense and Meilisearch are excellent — simpler ops than Elasticsearch, great developer experience, built-in typo tolerance. For 10M–30M documents, D is a legitimate answer that wins on simplicity. > > > At 100M documents with strict p99 requirements and complex relevance tuning, you start hitting their limits: distributed indexing is less mature, fine-grained scoring customization is constrained, and operational tooling at scale is thinner than Elasticsearch's ecosystem. For a smaller product, D is the right call. At 100M with a p99... **@joudawad** · 8 upvotes > **Why C misses the point (Redis cache):** > > Caching top queries is a real optimization — but it's not a search architecture. Your top 1,000 queries might cover 40% of traffic. The other 60% hits the slow path. Worse: every document update invalidates your cache logic. You've added complexity without touching the tail latency product is actually complaining about. > > > C is a band-aid. The p99 problem is still there the moment any user types something that isn't in the cache. **@joudawad** · 3 upvotes > Also, it would mean a lot to me if you could support my content and stay in touch 🙏 > > - YouTube: [https://www.youtube.com/@system-design-lab](https://www.youtube.com/@system-design-lab) > - LinkedIn: [https://www.linkedin.com/in/joud-awad/](https://www.linkedin.com/in/joud-awad/) > - Medium Blog: [https://joudwawad.medium.com/](https://joudwawad.medium.com/) > - Substack: [https://joudawad.substack.com/](https://joudawad.substack.com/) --- [View this post on daily.dev](https://daily.dev/posts/45-60-days-system-design-questions--rtkojksa7)