DEV Community: Thuve Rakan

Beyond Development: What It Really Takes to Build Enterprise Applications

Thuve Rakan — Fri, 04 Sep 2026 21:53:02 +0000

Lessons from building 24hours.lk and its companion mobile suite, the 24 Eco System

Building an application is easy when everything is predictable. The database is clean. The API works. The user follows the expected flow. The server has enough resources. Nothing changes.

Real enterprise applications are nothing like that.

While working on 24hours.lk and the 24 Eco System mobile applications, I started to understand the difference between building something that works and building something that can survive in a real production environment. The most valuable part of the experience wasn't creating screens — it was dealing with everything that happens behind them.

It Started Looking Like a Normal Application

At first, an application can look deceptively simple: a user opens the app, authenticates, views some data, submits something. The backend processes the request. The database stores it. Done.

But that simple flow hides a much larger engineering problem:

What happens if two requests arrive at exactly the same time?
What happens if the database becomes slow?
What happens if the mobile app is running an older API version?
What happens if a user closes the app halfway through an operation?
What happens when thousands of records need to be retrieved?
What happens when one service goes down but the rest of the ecosystem keeps running?

That's where enterprise development really begins.

1. The Architecture Becomes More Important Than the Feature

One of the biggest mindset changes I experienced was realizing that a feature is never really isolated. A new feature can touch mobile UI → API → authentication → business logic → database → storage → notifications → infrastructure, all at once — and changing one part can unexpectedly affect another.

Because of that, I had to think about things like:

Separation of concerns
API contracts
Service boundaries
Database relationships
Reusable business logic
Error propagation
Authentication flows
Backward compatibility
Deployment strategy

The question was no longer "How can I build this feature?" It became "Where should this feature actually live inside the architecture?" That's a completely different way of thinking.

2. The API Is the Contract Between the Ecosystem

When both web and mobile clients consume the same backend, the API becomes extremely important — a small API change can affect multiple clients at once.

24hours.lk Web
       │
       ├──────────────┐
       │              │
       ▼              ▼
     API Layer → Business Logic
       ▲              │
       │              ▼
       │           Database
       │
24 Eco System Mobile

This means an API can't simply be designed around what's convenient for one screen. It needs to account for request validation, response structure, pagination, filtering, authentication, authorization, error handling, version compatibility, performance, and mobile network conditions. The backend becomes the common language spoken by every application in the ecosystem.

3. Database Design Becomes a Real Engineering Problem

Working with real application data completely changes the way you think about databases. A database isn't just CREATE TABLE — or CREATE COLLECTION — and moving on. You have to think about how the data will grow, how frequently it will be queried, which fields need indexes, what happens when millions of records exist, and whether a relationship should be normalized or denormalized. Sometimes a query that looks perfectly reasonable during development becomes extremely expensive in production.

That pushed me to think more about:

Indexing strategies
Query optimization
Data relationships
Pagination
Transactions
Connection pooling
Data consistency
Migration strategies
Read/write patterns

The database isn't simply storage. It's part of the application's performance architecture.

4. Concurrency Creates Problems You Don't See Locally

One of the more interesting things about enterprise applications is that multiple users can perform operations at the same time. Imagine two requests modifying the same piece of data within milliseconds — both can individually look correct, but together they can create an inconsistent state.

This introduces concepts like race conditions, atomic operations, transactions, isolation levels, idempotency, and optimistic/pessimistic locking — the kinds of problems you rarely notice when you're the only person using your development environment. Production is different: the system doesn't execute your code once. It executes it concurrently and unpredictably.

5. Authentication Is More Than Login

Implementing authentication taught me that "login" is only the visible part. Behind it are questions like:

Who is this user?
How long should their session remain valid?
What happens when their token expires?
What permissions do they have?
Can this user access this resource?
What happens if the request is replayed?

This introduces concepts such as access tokens, refresh tokens, session management, role-based access control, permission systems, token expiration, secure credential handling, and OAuth flows.

Authentication answers "Who are you?" Authorization answers "What are you allowed to do?" Enterprise systems need both.

6. Mobile Development Introduces Another Layer of Complexity

The 24 Eco System mobile applications introduced challenges that don't exist in quite the same way on the web. A mobile app operates under very different conditions. The user might have:

Slow internet
No internet
An outdated app version
Limited device resources
Interrupted requests
Background restrictions
A different screen size or OS version

The server can be perfectly healthy while the user still experiences a failure. That means mobile applications need to be designed around unreliable environments — which changes how APIs, caching, error handling, loading states, retries, and synchronization all need to be approached.

7. Performance Is a Full-Stack Problem

When an application feels slow, the problem isn't necessarily the frontend. It could be frontend rendering, network latency, API processing, a database query, an external service, or server resources. A request that takes two seconds might actually break down like this:

Client rendering       150ms
Network                250ms
API processing         100ms
Database query       1,200ms
Response processing    300ms

Suddenly, the "frontend is slow" assumption becomes completely wrong. This made performance optimization much more interesting — you need to identify the actual bottleneck instead of optimizing randomly.

8. Production Errors Are Completely Different From Development Errors

Local development gives you a comfortable environment. Production doesn't. You start encountering problems caused by:

Environment configuration
Incorrect secrets
Database permissions
Network failures
DNS
SSL
Deployment differences
Resource limitations
Unexpected user inputs
Third-party service failures

And sometimes the most frustrating error is the one that simply says "Something went wrong."

Now you need observability. You need logs. You need meaningful error messages. You need to know what happened, where it happened, which request caused it, which user or service was involved, and what the system was doing at that moment. This is where logging, monitoring, tracing, and structured error handling become essential.

9. Deployment Changes the Way You Write Code

There's a huge difference between "it works on my machine" and "it works reliably in production." Deploying enterprise applications introduced another layer of engineering thinking — build processes, environment variables, production configuration, database migrations, domain configuration, SSL/TLS, CI/CD, server resources, rollbacks, backups, and monitoring.

A deployment isn't simply uploading code. It's changing a live system — which means every deployment needs to be treated carefully.

10. Backward Compatibility Is a Real Problem

One of the most interesting challenges of working across web and mobile is that users don't all run the latest version. Imagine the backend changes its response structure today — the web app updates immediately, but thousands of mobile users might still have an older version installed. Now the backend has to serve different generations of clients at once.

This is where API versioning, backward compatibility, deprecation, feature flags, and migration strategies become important. You aren't only developing for today's application — you're developing for multiple versions of yesterday's application as well.

11. Security Becomes a Continuous Battle

Enterprise applications are attractive targets because they contain valuable data, so security has to be considered at every layer:

Client → Authentication → API Gateway / Server → Authorization → Business Logic → Database → Infrastructure

A secure frontend doesn't compensate for an insecure API. An authenticated API doesn't compensate for broken authorization. A secure API doesn't compensate for exposed database credentials. Security is a chain, and the weakest link matters.

12. The Hardest Bugs Are Usually Not Syntax Errors

The most interesting bugs aren't usually undefined is not a function — those are easy compared to bugs caused by system behavior:

A request succeeds but the UI doesn't update.
Two operations happen simultaneously.
A mobile client sends an outdated payload.
A database query becomes slow only with large datasets.
A token expires mid-request.
A deployment works locally but fails in production.
A service returns successfully before another service has finished processing the data.

These problems require system-level debugging. You need to follow the request across the architecture instead of staring at one file.

13. Enterprise Development Changed How I Debug

Earlier, debugging often meant "find the error, fix the code." Now I think more like "what is the system doing?" — tracing the flow:

User Action → Frontend → Network Request → Authentication → API → Business Logic → Database → External Service → Response → Frontend State

The error might originate in one layer but appear in another. That's why understanding the complete system is more valuable than understanding only one framework.

14. The Technology Stack Is Only Half the Story

Working on 24hours.lk and the 24 Eco System also taught me something important: knowing a framework is not the same as knowing software engineering. You can learn a framework, a programming language, how to build APIs — but enterprise development also requires understanding distributed systems, databases, networking, security, concurrency, caching, scalability, observability, deployment, and reliability.

The deeper you go, the less the problem is about syntax. It becomes about systems engineering.

What I Really Took Away

Working on 24hours.lk and the 24 Eco System changed my definition of a "developer." I no longer see an application as a collection of screens. I see it as a living system — one where users generate requests, APIs move data, business logic makes decisions, databases maintain state, infrastructure keeps everything alive, security protects the entire chain, and monitoring tells us when something goes wrong. Every one of those components has to work together.

The biggest lesson wasn't learning another framework. It was learning to think beyond the code.

Because building an enterprise application isn't about making something that works.

It's about building something that can keep working when reality starts attacking it.

[Boost]

Thuve Rakan — Wed, 05 Aug 2026 20:02:37 +0000

Fixing RBAC bugs in K8s 1.31

Le Beltagy

Aug 1

I Learned Go in 3 Weeks. Yesterday, My Code Merged into k9s.

#go #kubernetes #opensource #beginners

8 min read

Why Redis Is Essential in Enterprise Applications

Thuve Rakan — Wed, 05 Aug 2026 19:07:04 +0000

In today's enterprise world, users expect applications to be fast, reliable, and always available. As businesses grow, traditional databases alone often struggle to handle increasing traffic and real-time demands. This is where Redis becomes a game changer.

What is Redis?

Redis (Remote Dictionary Server) is an open-source, in-memory data store that can be used as a cache, database, message broker, and streaming engine. Because it stores data in memory instead of on disk, Redis delivers responses in milliseconds.

Why Enterprise Applications Need Redis

Lightning-Fast Performance

Redis dramatically reduces response times by storing frequently accessed data in memory. Instead of querying the primary database for every request, applications can retrieve cached data almost instantly.

Example: User profiles, product catalogs, and application settings can be served from Redis rather than repeatedly querying the database.

Reduces Database Load

Enterprise systems often experience thousands or even millions of requests per day. Redis acts as a buffer between the application and the database, significantly reducing database queries and improving overall system stability.

Better Scalability

As your business grows, traffic increases. Redis helps applications scale horizontally by handling repeated read operations efficiently, allowing backend databases to focus on critical transactions.

Session Management

Managing user sessions across multiple servers can be challenging. Redis provides centralized session storage, making it ideal for load-balanced and distributed applications.

Real-Time Applications

Redis is widely used for:

Live notifications
Chat applications
Gaming leaderboards
Live analytics dashboards
Real-time tracking systems

Its publish/subscribe (Pub/Sub) capabilities make instant communication possible.

Background Job Processing

Enterprise applications often need to process emails, reports, image uploads, and notifications asynchronously. Redis works seamlessly with job queues, allowing background tasks to run without slowing down the user experience.

High Availability

Redis supports replication, clustering, and automatic failover, ensuring applications remain available even if a server fails.

Common Enterprise Use Cases

API response caching
Authentication and user sessions
Rate limiting APIs
Shopping cart storage
Real-time notifications
Leaderboards
Background job queues
Distributed locking
Analytics and counters

Benefits at a Glance

Millisecond response times
Reduced database workload
Improved application scalability
Better user experience
Lower infrastructure costs
High availability and reliability
Excellent support for real-time features

Best Practices

Cache only frequently accessed data.
Set expiration (TTL) for cached items.
Monitor memory usage regularly.
Use Redis clustering for high-traffic systems.
Never use Redis as the only permanent storage for critical business data unless your architecture is specifically designed for it.

Final Thoughts

Redis is more than just a caching tool—it's a core technology that enables modern enterprise applications to deliver exceptional performance, scalability, and reliability. Whether you're building an e-commerce platform, SaaS application, banking system, ERP, or social platform, integrating Redis can significantly improve user experience while reducing backend workload.

As enterprise applications continue to grow in complexity and scale, Redis remains one of the most valuable technologies for building high-performance systems.

My Internship Journey: Learning Beyond the Classroom

Thuve Rakan — Wed, 29 Jul 2026 18:29:48 +0000

Internships are one of the most valuable experiences for any undergraduate, and I am grateful to have completed mine. This journey allowed me to bridge the gap between academic knowledge and real-world software development while improving both my technical and professional skills.

From my very first day, I was introduced to a collaborative development environment where teamwork, communication, and problem-solving played a major role. I had the opportunity to work on real projects, understand industry workflows, and learn how professional software products are built and maintained.

Throughout my internship, I gained hands-on experience with modern web technologies, version control using Git, API integration, debugging, and deploying applications. I also learned the importance of writing clean, maintainable code and following industry best practices. Working alongside experienced developers helped me improve my coding standards and exposed me to new tools and frameworks.

One of the biggest lessons I learned was that software development is not only about writing code. It involves understanding user requirements, collaborating with team members, managing deadlines, and continuously learning new technologies. Every challenge I encountered became an opportunity to grow and improve my skills.

Beyond technical knowledge, this internship strengthened my confidence, communication, time management, and ability to work effectively in a professional team. The guidance and support from my mentors played a significant role in my growth throughout this journey.
Looking back, this internship has been a milestone in my career. It has given me practical experience, valuable industry exposure, and a clearer vision of the software engineering field. I am excited to apply these lessons in my future projects and continue growing as a developer.
I would like to express my sincere gratitude to my mentors, teammates, and the organization for providing me with this incredible opportunity. This experience will always remain an important part of my professional journey, and I look forward to embracing new challenges in the future.