Bharath Krishna

The best advice I got on my promotions as a software engineer was from a Principal Architect at Amazon after he told me his story of getting promoted to Principal, and this has stayed with me my whole career. He said, very simply: > Your architecture can be a love letter to your technical brilliance, > but if it does not move customer and company goals, it will not move your level. That hurt a little. Because I recognised myself in it. A few years ago I wanted to design something with every shiny thing in the book: API Gateway, Lambda, DynamoDB, event bus, the works. On paper it was beautiful. In reality it was expensive, slow to ship, and did not match the skills of the team that would maintain it. So we shipped a hybrid architecture instead. Fewer moving parts, more reuse of existing services, cheaper to run, easier to hand over. Over time, here is how my thinking about promotions changed. 1. Start from the business goal, not the tech stack Before talking about Kafka vs SQS or MySQL vs DynamoDB, answer this first: What money, risk, or customer pain will this remove? Promotions track that, not the number of services in your diagram. 2. Ship finished products, not clever demos Leaders remember the feature that went live, stayed stable, and earned or saved real money. Drive the entire lifecycle yourself: design, build, launch, oncall, cleanup, docs. 3. Make the team faster, not just yourself Tools, scripts, templates, better CI, better dashboards. If people quietly say “things move faster when you are on this” your manager already has half a promotion case. 4. Do your share of the unsexy work Oncall, migrations, bugs, incident reviews. Senior folks who avoid this slow the entire org. Senior folks who lean into it become trusted very quickly. 5. Grow people, not just systems Mentor juniors, run design reviews, write clear docs, set standards. When your manager sees that you are already acting like the next level, formal promotion becomes a catch up, not a favour. 6. Be proactive about your promotion, not obsessed with it Have periodic one to ones. Talk about where you want to go and ask what evidence your manager would need to support that. Remember your manager has ten other people to manage. It is your responsibility to make your impact visible. Do not be desperate. Understand the timelines and work within them. As you get close to the boundary, collect the missing data points: impact metrics, incident write ups, design docs, peer feedback. Make the story easy to tell. Most importantly, work for the business, not for promotion-driven development. If your roadmap only exists to tick boxes on a promotion rubric, people can feel it. If your roadmap clearly creates value, saves cost, or reduces risk, promotion becomes the natural side effect. So instead of asking “What new tech can I use this year?” Ask, “Where can I create obvious business impact and leave the system and the people around me better than I found them?”

182

15 Comments

Someone lost their job at Amazon when they were expecting their first child and looking forward to being a parent. Now their whole world is upside down. Someone got laid off in October, fought hard to find an internal role, and still got impacted in the next round. Someone who spent 10 years in the company, worked across three teams, and managed people with care, also lost their job today. It happens quickly. You get an email, the next thing you know you are locked out of the system, badge stopped working, chats gone. It feels like you were never part of the place to begin with. Layoffs are the worst part of this industry, and you can do almost nothing to prevent them once a list is made. A few things I want to say to anyone who got impacted today: 1. A spreadsheet decision is not a measure of your intelligence, your kindness, or the value you created for users and teammates. Please be kind to yourself. 2. Take time to process. Cry, vent, sleep. You are a human who just had their safety rug pulled, not a robot who must instantly “bounce back.” 3. The projects you shipped, the skills you built, the people you helped, all of that is real. A layoff cuts pay, not your track record. Do not feel like you’re not strong enough to find your way again, you are. 4. Tell friends, ex colleagues, mentors what happened. Ask for referrals, mock interviews, resume reviews, even just calls where you talk about anything except work. If you were not impacted, check on the ones who were. Nobody chooses to be on the receiving end of that email. The least we can do is remind them that the email is not the end of their story.

973

37 Comments

At 3 AM on a Wednesday, Amazon needed me. I wasn’t even on that team anymore. Back when I was an SDE at Amazon, a Sev-2 had hit one of our services. Many customers were impacted. The team had been chasing it for hours. Still, they called me. I rolled out of bed, opened my laptop, and joined the bridge. The tricky part was that the fault started a week earlier. A code change had shipped behind a flag, traffic ramped slowly, and the failure signature was noisy. Logs were chatty in all the wrong places and silent where we needed them most.Dashboards showed errors, but no clear line to the root. We did unglamorous things. We wrote a minute-by-minute timeline. We diffed deployments, configs, and flags across regions. We checked queue backlogs and retry storms. We sampled logs with new filters. We bisected the traffic ramp. We rolled back the smallest safe thing first. Then we added one log, in one hot path, and the picture snapped into focus. By sunrise, we had the root cause and a fix. The impact was contained. Customers recovered. What stayed with me was not the fix. It was why they called. They did not call because I am smarter. They called because, over months, I had done the boring work. I wrote runbooks when no one asked. I paired with juniors on their first on-call. I shared context so others could make decisions without me. I showed up when it was not my ticket. Trust is not built in one night. It is built in all the small days that come before it. Ownership is simple. If it affects your customer, it is your problem. Org charts are for payroll, not for 3 AM. If you are early in your career, remember this: → Document the weird corners when you discover them. → Add one useful log where it hurts, not twenty where it is easy. → Keep a living checklist for rollback, not a static wiki page. → Teach one person the thing you just learned. → Read your dashboards when things are calm, not only when they are red. At 3 AM, you will not rise to the occasion. You will fall to the level of your habits. Build the right ones while the house is quiet. That’s how you earn trust that lasts beyond teams and ownership that outlives org charts. A few days later, this moment turned into an accolade from the team..  a reminder that trust is built long before it’s tested :)

334

45 Comments

I’ve interviewed to 500+ candidates combined in the last 7 years of my journey at Amazon, Cars24, and now Nielsen…(150+ in the last 1 year alone) This is the best guide I can give you on how to pass technical interviews and what 90% of candidates often forget while interviewing. (Btw, I also used this to switch jobs 3 times in my career) [1] Don’t rush to code, talk through the problem first Many candidates fail because they panic and try to impress with fast coding but the right move is to slow down and talk out loud. Break the problem into conditions, use a whiteboard or pseudocode if needed. Even a simple question becomes easy once you write the logic in plain English. [2] Think before you type Take your time to understand the requirements before you touch the keyboard. Rushing leads to bugs. Thoughtful implementation shows maturity. Even if you know the answer, show structured thinking and clear decision-making. [3] Always explain your choices, even if they’re wrong Interviews are less about the correct answer and more about your thought process. Prefer saying something logical than staying silent. For example: “I’m using a regular for loop here because it gives me better control.” [4] Practice talking while solving Most people freeze not because they lack skill  but because they don’t rehearse speaking + thinking. Get used to explaining your logic out loud while coding. Follow the rule: ABC – Always Be Chatting (not just coding). [5] Don’t sit in silence when you're stuck Silence kills momentum. If you get stuck, ask questions: “Should I print this line-by-line or return a result array?” Showing that you can stay calm under pressure matters more than getting it perfect. [6] Prefer readable, scalable solutions over clever tricks Avoid language-specific shortcuts (e.g., JS type coercion). Use modulo instead of overcomplicating divisibility logic. Interviewers prefer clean, maintainable code that works across languages. [7] Optimize code for simplicity and future changes If new conditions are added (like printing something for multiples of 7), your code should be adaptable. Use a variable-based solution instead of nested `if-else` trees. Think like an engineer, not just a coder. [8] Know your basics (like Big-O) Be ready to talk about time complexity. Even if the problem is trivial, say something like: “We’re iterating 100 times, so technically O(n), but since it's a fixed 100, it simplifies to O(1).” Technical interviews are not just a test of memory or speed. They’re also a test of clarity under pressure, structured thinking, and communication.

138

11 Comments

You are in a system design interview at Amazon for an SDE-3 role and the interviewer has given you the question to Design Netflix. He then asks a follow up to you: How does Netflix knows when to show: Are you still watching? Is it just time-based? If it were time-based, you would see it every time. So what is actually going on under the hood? Both look like a simple pop-up. Underneath, it is a mix of product thinking, client logic, and backend events. Btw, if you’re preparing for system design/coding interviews, check out our mock interview tool. You can use it for free here: https://lnkd.in/gpCn7t2T [1] Start from the product goals The feature is not only about nagging people. - Save bandwidth and CDN cost if the viewer has slept or walked away - Avoid autoplaying potentially sensitive content in an empty room - Protect kids if parents start a show and leave the TV on - Do all this without annoying active binge watchers So the design must answer one question: "When is the user probably not here any more" [2] Naive design - pure timer Simplest idea: - If playback has been running for 2 hours, show Are you still watching - If user clicks "Yes", reset the timer Why this is weak: - Someone can binge 5 episodes in a row and gets interrupted in the middle of an intense scene - Someone can start a show, walk away after 5 minutes, and the platform will keep streaming for the next 2 hours - It ignores how many episodes were auto played, device type, time of day, user habits  [3] Realistic design - session and engagement signals Think in terms of a "watch session" and "engagement events". Signals the client can track: - Play, pause, seek, volume change - Episode finished and next episode auto started - Remote or keyboard input, UI navigation - Screen on or off events from the device - For mobiles: app background or locked state A common heuristic could be: - Count how many episodes have auto played without any user interaction - Track how long it has been since the last button press or navigation - Only trigger the prompt when both are high enough Example rule: - If 3 episodes in a row have auto played - And there has been no interaction for 45 minutes - Then, before starting episode 4, show Are you still watching This feels much smarter: - Active viewers who pause, skip intro, change volume keep resetting the "engagement clock" - Sleeping viewers do not touch anything, so the next episode is blocked by the prompt  [4] Client heavy vs server heavy design You can talk about two design choices. Client first: - All logic runs inside the app on TV, mobile, or web - Client keeps an in memory session model and decides when to show the popup - It still sends telemetry events to backend for analytics and future tuning Pros: - Works even with flaky network - Highly responsive, no extra server round trip Cons: - Logic must be implemented and updated across many platforms - Harder to quickly roll out rule changes Continued ↓

184

12 Comments

Positive thoughts to my ex-colleagues at Amazon. A tough period indeed. The first few days after a layoff feel surreal. The silence after the news can be deafening, and the urge to immediately fix everything is strong. But here’s the truth most people don’t tell you , it’s okay to pause. Rest. Let your brain and body catch up to what just happened. Clarity only comes after you exhale. Once you’ve had time to breathe, start treating the next chapter like a strategic reboot. Use this moment to re-evaluate what kind of work excites you and what kind you never want to return to. The layoff might have closed a door, but it also cleared space for something better aligned with who you are now. When you’re ready to re-engage, AI tools can take a lot of the heavy lifting out of the job search. ChatGPT can help you tailor your résumé for each role and practice interview questions. Tools like Rezi and Teal can optimize your resume for applicant tracking systems. Even LinkedIn’s own AI features can help you write stronger “About” sections or suggest better keywords to match your profile with recruiters’ searches. Use this time not just to find another job, but to redesign your career story. A layoff isn’t the end of your professional identity. It’s a forced pause that can turn into your most creative rewrite yet. #Layoffs #CareerGrowth #AItools #JobSearch #Resilience #LinkedInCommunity

10

2 Comments

As a manager at Amazon, I had to manage layoffs and support the team members during tough time. But the ones who remained unaffected were looking at me for the company strategy and actions. Did i have all the answers? no Did i pretend I have answers and give false hopes? no 💬 “Aren’t leaders supposed to have all the answers?” I used to think so too. Early in my career as a manager, I believed showing uncertainty would make me look weak. So I pushed myself to always project confidence, even when I was unsure. But here’s what actually happened: • My team felt I wasn’t approachable. • They hesitated to share their own doubts. • We missed chances to collaborate better. The turning point came when I openly admitted in a meeting: 👉 “I don’t know the answer to this yet. Let’s figure it out together.” Instead of losing credibility, something surprising happened: • My team leaned in. • People spoke up with ideas. • Trust deepened. That’s when I learned: vulnerability is not weakness. It’s leadership authenticity. Even during layoffs, I openly told them what I knew and also made them part of the ride. Instead of giving sugar coated answers and false promises about bright future, I showed them the future I will ensure for them. The results - I had zero attrition in my team even though org was facing major attrition due to hncertainity - team was motivated by the vision I had, and were fully committed to make that a reality - the team got opportunities to work on strategic bets and not just do the minimum to save the job. Here are some practical ways to practice vulnerability at work: 🔹 Admit mistakes openly — and share what you learned. 🔹 Ask for help when needed — it creates space for collaboration. 🔹 Acknowledge your limits — no one trusts a “perfect” leader. 🔹 Celebrate your team’s expertise — you don’t need to outshine them. Here’s the paradox: 👉 Leaders who pretend to know everything become less believable. 👉 Leaders who show vulnerability become more relatable, respected, and trusted. 💡 My biggest lesson: A leader’s job isn’t to be flawless. It’s to be real. Over to you — have you ever seen vulnerability strengthen (not weaken) a leader’s influence? #leadcode #rohitsharma #leadership

46

1 Comment

When you join a new org or switch teams in the same, it is quite an unsettling and borderline anxious experience. Here are a few things that I did to ramp up faster. 1. I consciously made an effort to remain unblocked 2. I read a ton of code and its history, sometimes even unrelated 3. I asked questions about the past, the present, and the future 4. I took up relatively mundane tasks - cross-team work, tests, and docs 5. I extended a helping hand in whatever capacity I could 6. I proactively met skip-level leaders and managers to understand the vision Some companies do have a culture of pairing up with someone existing in the team, but even if you do not get a mentor, it is important that you still navigate the situation and ramp up as quickly as you can. The above list is not exhaustive, by any means, and hence you can always add things that you find helpful in your context. but the lowest common denominator is to show extreme intent and interest to get output and drive outcomes. Hope this helps.

996

25 Comments

One thing your manager will never tell you Your promotion depends less on your performance and more on whether your team is actually growing. When I joined Amazon as an SDE-1, my team had 25 people. By the time I became Senior, it had 120+. Looking back, my “fast promotion” wasn’t magic. The org was expanding like crazy and growth creates opportunity. Here is the part people don’t like hearing: ❌ If your team hasn’t grown in years, your career won’t either. ❌ It doesn’t matter how good you are. There is nowhere to go. ❌ The only real path up becomes waiting for someone above you to leave. So if you want to grow faster: Choose teams that are growing. Not teams that are comfortable. Skills matter. Environment matters more.

1,039

21 Comments

6 months into my job at Amazon, I broke production and thought this was the day my career ended because the company lost a lot of revenue...This is the story of one of the biggest learnings of my career. I was on an ad tech team. I was trying to learn the ad pipeline, went a bit too confident with a change, and triggered a failure. For 7–8 hours, ads were not being served. The moment I realised what had happened, my heart just dropped. I pinged my senior, called it out clearly, and stayed glued to the incident channel. Here is what surprised me. No one shouted. The first questions were: - “What changed?” - “How do we restore?” - “How do we stop this from spreading?” We rolled back. Checked the data. Verified that the pipeline was healthy again. Only after things were stable did the real work begin. That was the retrospective. We walked through the timeline, and I explained exactly what I did. We realised there was a big documentation gap. Some critical behavior of the pipeline lived only in people’s heads, not in any design doc or runbook. The conversation was not “Why did you mess this up.” It was “How did the system allow this to happen and how do we make sure the next person does not fall into the same trap?” I wrote the COE (Correction of Error) doc. My senior manager liked how honest and detailed it was. He told me, “You made a serious mistake. You also did the right things after. You reported it quickly, stayed on the fix, and left the system stronger than you found it.” That has stayed with me ever since. A healthy engineering culture does not pretend failures will never happen. It assumes they will. So it rewards people who: - Surface problems early instead of hiding them - Take ownership of their changes - Care enough to improve docs and processes after an incident - Focus on learning, not on finding a scapegoat Looking back, that outage was expensive for the company, but priceless for me. It taught me that good teams judge you not only by the bugs you ship, but by how you behave when those bugs show up in production. You will break something important at some point in your career. The question is not “How do I avoid mistakes forever?” It is “When it happens, will I have the courage to own it and the maturity to learn from it?”

545

28 Comments

Stop treating Load Balancers and Reverse Proxies as the same thing. In System Design interviews (and production incidents), the distinction matters more than you think. As we move from SDE1 to SDE2, we stop asking "How do I make this code work?" and start asking "How does this system scale and survive failure?" Here is the deep dive on two critical components that often get conflated. 1. The Load Balancer (The Scaler) Primary Goal: Availability & Horizontal Scaling. The Job: Spreading traffic across multiple compute resources to eliminate Single Points of Failure (SPOF). The SDE2 Nuance: You need to know the difference between Layer 4 (Transport) and Layer 7 (Application) balancing. L4 is fast; it forwards packets based on IP/Port without looking inside. L7 is smart; it terminates the connection, reads the HTTP headers/path, and routes /api differently than /images. 2. The Reverse Proxy (The Shield) Primary Goal: Security, Unification & Offloading. The Job: Sitting in front of backend servers to hide their topology and IP addresses. The SDE2 Nuance: SSL Termination. Decrypting HTTPS handshakes is CPU-intensive. A Reverse Proxy handles this heavy lifting at the edge, allowing your backend application servers to focus purely on business logic (and communicate via HTTP inside the private VPC). The Reality Check 💡 In modern architecture (and cloud environments like AWS ALB or tools like NGINX), the lines blur. We often use a single component to perform both roles simultaneously—terminating SSL (Reverse Proxy) and then distributing the request to a pool of instances (Load Balancer). But knowing which function you are tuning—and why—is what separates a mid-level engineer from a senior one. Questions for the network: Do you prefer handling SSL termination at the Load Balancer level or strictly on the application server for end-to-end encryption? #SystemDesign #SDE2 #SoftwareEngineering #Scalability #DistributedSystems #DevOps

66

1 Comment

I went from Senior PM to VP in less than 3 years. If I could do it all over again, here’s what I would change. I was a Sr. Director, and the Global Head of DEI for one of the world’s leading EDA companies, a top innovator in chip design. But eventually, I started to feel like I was hired to be the face of the function, and not the actual leader of the function. Reflecting on that experience as that company's first-ever DEI leader, there were natural growing pains I probably should have stuck around for. At the same time, another company came calling with a VP title, the highest base salary I’d ever seen, a 40% bonus, and a very nice stock package. It felt like a no-brainer. But here’s what happened: I left because I felt handcuffed in my Sr. Director role, and I let the money and title at the new company make the decision for me. What I didn’t do? The simplest thing. I didn’t check the company’s financial health. If I had just looked at their balance sheet or quarterly reports, I would have seen the red flags. Instead, I got caught up in the base pay and made a bonehead decision. The result? The 40% bonus came in the form of 10% and as bad as we were doing financially, I was thankful for that. The stock??? It dwindled down to nothing, eventually forcing the company to go private. And after I was there for a year and a half, the company laid off two-thirds of its workforce, and I was part of the fallout. The hardest part? If I had stayed at my previous company, I’d be a millionaire today just from the stock alone. Here’s what I learned: - Don’t just chase the salary, study the stability. - Culture and values outlast compensation packages. - Protect your long-term wealth, not just your short-term income. If you’re considering a new opportunity, don’t make the mistake I did. Look past the base pay and into the financial facts and future of the company! They say hindsight is 20/20, so I would love to hear from you. What’s one career decision you wish you could do over again and why?

54

Amazon Layoffs Incoming — And This Time, It's Principal Engineers Rumors[1] are circulating that Amazon is preparing another round of layoffs — and what's especially striking is that principal engineers are among those being targeted. This is a sharp reminder that: - Being senior doesn't make you immune to layoffs - As you climb the eng ladder (which is just another term for the corp ladder), you have to sustain your performance/impact, so cruising is not an option compared to common beliefs - Companies are entities that try to maximize revenue/profits – being laid off sucks, especially if you're on parental leave (or any kind of leave), on a precarious visa situation etc. I think we have seen enough layoffs in tech companies that these are probably the new normal. Companies who struggle to fire people through a regular process, will rely on layoffs to occasionally clean house. This sucks.

503

36 Comments

Back in 2022, I went from @amazon.com → @google.com when I cracked the Google SWE role after leaving Amazon and working there for 2+ years. Working at Google had been a very old dream of mine, and to me, it wasn’t your average switch; it was a long-held dream coming true. Growing up, I desperately wanted to go to an IIT, but I couldn’t qualify, mostly due to my own faults. But my love for computer science never faded, and working at Google became that “impossible” dream I quietly held on to. So, when a recruiter finally messaged me about interviewing at Google, I celebrated as if the offer had already come. And that brings me to the topic of this post. I’ve been getting a lot of queries about the interview process, so here’s how Google hires SDEs: 1. Recruiter Call The recruiter wants to know if you’re a legit fit for the role and if you’re interested. It’s mostly background, why you want to move, your comp expectations, etc. 2. Technical Phone Screen You get a link to code, usually Google Docs and the interviewer throws a DSA problem your way. They care a lot about how you think, not just if you finish. I had one phone screen, but sometimes you get two if they’re not fully convinced (like if you struggled with speed or communication). 3. Onsite, Coding Rounds I had four rounds of coding onsite. Here’s how it went for me: 1st coding round: Crushed it. Hit all the edge cases, explained everything as I went. 2nd round: Also went well. Not perfect, but I felt solid coming out. 3rd round: This one didn’t go so well. Google’s process is process-oriented, not results-oriented, so if they see a gap, they don’t just write you off. They gave me a fourth coding round to collect more signals and see if that third round was just a fluke. So if you’re ever in the process and get called for an extra round, don’t panic. It means you’re still in the game, and they want to give you a fair shot. 4. (Sometimes) Behavioral/Googliness Round This one is honestly hit or miss. Some people get a behavioral round, some don’t. They just want to see how you reflect, how you work with others, and your approach to conflict or feedback. 5. Team Matching & Hiring Committee If your interview rounds go well, all positive, you’ll get connected to team-matching first. Team-matching is like speed dating with different teams to see where you’d fit. Once a team is interested and agrees to take you in, your packet (your interview feedback and team interest) goes to the Hiring Committee for final approval.

579

45 Comments

Micron, SK Hynix, and Samsung stocks are soaring but few understand why.   1. The structural reason:   - Memory, in particular High-Bandwith Memory (HBM) has become crucial to run LLMs for billions of users - Running LLMs is mostly is memory-bandwidth bound, not compute-bound - During decode, GPUs spend more time fetching weights and KV cache than doing math, making HBM the primary bottleneck   2. The supply chain reason: - As demand soared, the major players shifted production capacity to high-margin HBM - That led to undersupply of other memory types (SRAM, DRAM) which are still needed for AI   What this means for…   1. Business leaders Memory cost will drive up GPU pricing Even if you don't buy chips, AI infra costs will likely rise as supply chain players will pass on costs   2. Entrepreneurs After decades of silence, there is massive opportunity in innovating memory Its still overlooked by many but we will soon see more high valuation memory startups which will become attractive acquisition targets for the 3 big incumbents   📷: FT   …   Did you find this helpful? ♻️ Repost this to inform your network 🔔 Follow me for more AI insights 🔖  Subscribe to my newsletter

15

4 Comments

I’ve interviewed 30+ Sr. SDEs going for L5/L6 level roles at Meta, Google & Amazon. A lot of them failed the database question in the SD round. The mistake? They name the technology before they understand the workload. If you want the 1Cr+ total compensation, you have to stop thinking like a coder and start thinking like an architect. Here is the exact 4-step framework I use to map any workload to the perfect tech stack: Step 1: Label the workload Before naming any database, answer 3 questions in your head. 1. Is this OLTP vs Analytics vs Search/Logs 2. Is traffic read heavy, write heavy, or balanced 3. Do we need strong consistency or is eventual consistency fine Once you know this, the search space is already much smaller. Step 2: Choose the data model family Pick a model instead of a product: - Relational tables - Document - Key value - Columnar analytics - Time series - Search index Quick rules of thumb: - Complex relationships, transactions, money flows -> relational - Flexible JSON-like records, changing schema -> document - Simple id lookups, very hot keys -> key value - Heavy reporting on large history -> columnar analytics - Metrics or events over time -> time series - Free text search, fuzzy matching, ranking -> search index Step 3: Map to real technologies Now you can safely talk about specific tools. 1. Classic relational OLTP Use for: orders, payments, bookings, user accounts Tech: Postgres, MySQL 2. Distributed SQL for high scale or multi region Use for: same as above, but with very high scale or multi region writes Tech: CockroachDB, YugabyteDB, TiDB 3. Key value and caching layer Use for: sessions, feature flags, counters, rate limits Tech: Redis, Memcached 4. Document store Use for: user profiles, settings, content documents Tech: MongoDB, Couchbase 5. Wide column store Use for: large scale write heavy workloads, telemetry, big sparse tables Tech: Cassandra, HBase 6. Columnar analytics and OLAP Use for: BI dashboards, offline analytics, aggregates on billions of rows Tech: ClickHouse, other columnar warehouses 7. Time series and metrics Use for: monitoring metrics, IoT sensor data, time based events Tech: TimescaleDB, InfluxDB, Prometheus 8. Logs and search Use for: application logs, product search, log search Tech: Elasticsearch, OpenSearch Step 4: Internal decision flow, you can sketch In the interview, you can even draw a tiny flow like this: 1. Is it core transactional data with strong consistency needs    -> Yes: start with Postgres or MySQL    -> Need multi region or very high scale: move to CockroachDB / Yugabyte / TiDB 2. Is it analytics or reporting over large history    -> Yes: replicate into ClickHouse style columnar store 3. Is it metrics or time series    -> Yes: Timescale / Influx / Prometheus 4. Is it full text search or logs    -> Yes: Elasticsearch 5. Do we need very low latency for a small working set    -> Yes: add Redis cache in front of the chosen primary store

412

27 Comments