harisrid Tech News

“I fight for the users!” – Rinzler

Hi all,

I want to share huge tips for system design – how to think about building for your actors, your personas, and your users. Because when we built Enterprise-grade applications, we don’t just built for ourselves – we build for end customers, the employees of the industry we build for, third-parties, auditors, etc.. And in these 40 – 50 minutes, knowing end customers we built for majorly influences design evolution.

What a junior / inexperienced candidate does

Let’s imagine someone needs to build out a ride-sharing service. Ok, TC – the candidate – will probably think about two personas – matching drivers and riders. They’ll come up with business workflows such as :

1. Riders can making a booking
2. Riders can view their history of bookings
3. Riders can cancel a booking
4. Drivers can register and earn money on the platform

It’s a good start, and for the scope of 45 minutes, it’s justified. But what if I had more time or the interviewer ask the question of “Who else on the side might you build out for”? Ok, let’s dive!

What a more senior candidate does

A more experienced engineer recognized that there’s multiple parties in an organization.

Administrators – maintainers of web apps and databases
Business Analysts – execute ad-hoc analytical queries
Security specialists – ( who enforce rate-limiting, enterprise-wide policies )
DevOps Folks and Developers – they deploy changes, typically through CI/CD pipelines.

In the real-world, we need to think about other parties. And parties can come-and-go or change. In that case, we also need to think about the accommodating plug-and-play functionality and consequentially, microservices. Services which can be built as interfaces an application.

Alright, so what would their workflows resemble?

• Admin – a dedicated UI – or a separate portal, on an existing UI – to view all data, including sensitive data elements.
• Business Analysts/Data Analysts – they need minimal interfaces to retrieve analytical data, such as moving averages, running sums, or aggregations over different timeline granularities ( days, weeks, months ). A good designer would introduce a OLTP->OLAP ETL pipeline with a sequence of OLTP -> Read Service -> Kafka Queue -> Worker Pool write service -> OLAP. Afterwards, they’d talk about (A) Leveraging the OLAP DB’s pre-existing capabilities in the or (B) Build a UI/API to access data records.
• Business Employees – think of Design a Hotel Reservation System. We need to build not just for customers, but also the staff for hotels or a hotel’s employees, who need to update booking information in some database ( e.g. number of hotels, type of hotels, type of hotel rooms ).
• Content Creators – this comes up for questions like Design Netflix or Design Youtube, but we can’t just think about flows for the end users ( the viewers ). Turns out there’s complex pipelines and video chunkification that takes place for the creators
• DevOps – We need to think about spinning up microservices to deploy the latest version of a binary or a ML model. Can I build tools so that developers can build and deploy the latest version of their code? Can we set up a ML model store ( using S3 or similar technologies )?
• Financial Auditors and Regulators – you’ll see them come up for questions like Design a Stock Exchange or Design a Payments System. Financial ecosystems typically need a ledger-esque, immutable, append-only database showing a history of transactions – credits and debits.

Good Questions to ask:
1. Do we have to build UIs, or can we limit exposure to program APIs?
2. Do we need to add ACLS, security, AuthN, or AuthZ?
3. Do we need to think about SMS/JWT/other token-based mechanisms?